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Software  engineering  techniques  are  being  increasingly 
utilized  to  produce  low  cost,  reliable  computer  systems. 

These  methods  offer  a structured  approach  to  define  the  sys- 
tem requirements  and  the  system  design. 

I have  attempted  in  this  thesis  to  employ  some  of  these 
techniques  in  a different  application  from  that  in  which  they 
are  normally  used.  Bather  than  using  them  to  define  a non- 
existing  system,  I began  with  an  existing  computer  system, 
and  attempted  to  evaluate  its  success  at  meeting  user  expec- 
tations . 

I have  assumed  that  the  readers  of  this  thesis  are  fam- 
iliar with  computer  terminology.  A basic  knowledge  of  soft- 
ware engineering  principles  is  also  assumed. 

For  their  assistance  and  for  allowing  generous  usage 
of  their  equipment,  I would  like  to  express  my  gratitude  to 
the  Air  Force  Flight  Dynamics  laboratory,  and  my  sponsor,  hr. 
Bernie  Groomes.  For  his  guidance  and  encouragement,  I would 
like  to  thank  my  thesis  advisor,  llaj.  Alan  Boss.  For  supplying 
great  moral  support,  I offer  a special  thanks  to  my  lovely 
wife,  Suzi.  - - 
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Abstract 

This  thesis  is  an  evaluation  of  an  existing  computer 
graphics  system  using  structured  analysis  techniques.  The 
system  evaluated  is  the  IMLAC  PDS-^  minicomputer  at  the  Air 
Force  Flight  Dynamics  Laboratory,  Wright  Patterson  AFB. 

The  technique  used  in  the  evaluation  is  performed  in 
three  steps.  First,  the  existing  system  is  modeled  into  its 
logical  equivalent  using  bubble  charts.  This  model  shows  the 
flow  of  data  through  the  system,  and  the  activities  performed 
on  that  data.  Second,  a similar  model  is  produced  describing 
the  required  system  as  defined  by  the  users.  This  model  is  a 
representation  of  the  users'  desires  and  requirements,  and  is 
similar  to  a model  which  might  be  produced  during  the  require- 
ments definition  phase  of  a computer's  life  cycle.  The  third 
step  is  to  compare  the  two  models  to  evaluate  the  existing 
system's  effectiveness,  and  reveal  areas  requiring  modification 
for  full  utilization  of  the  system. 

Following  the  evaluation,  several  recommendations  and 
changes  are  proposed  to  increase  the  system's  capability  to 
meet  the  user  requirements. 
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EVALUATION  OP  AN  EXISTING  COMPUTES 
SYSTEM  USING  STRUCTURED 
ANALYSIS  TECHNIQUES 

I.  Introduction 

Objectives 

Structured  analysis  is  recognized  as  a valuable  tool 
for  performing  the  requirements  definition  phase  of  a system's 
life  cycle.  When  used  properly,  this  technique  provides  a 
step-by-step  procedure  for  completely  specifying  the  system 
parameters.  These  parameters  will  reflect  the  four  basic 
principles  of  software  engineering:  modifiability,  efficiency, 
reliability,  and  understandability  (Ref  8:21). 

The  purpose  of  this  thesis  is  to  employ  the  approach 
of  structured  analysis  towards  a different  application.  A 
formal  set  of  procedures  is  developed  to  apply  structured 
analysis  principles  to  the  evaluation  of  an  existing  computer 
system.  The  goals  of  this  evaluation  are  to  determine  specific 
areas  which  do  not  satisfy  the  requirements  established  by 
the  users  of  the  system,  and  to  define  what  modifications 
are  necessary  to  meet  these  requirements.  The  system  to  be 
analyzed  is  the  IMLAC  PDS-4  graphics  system  located  at  the 
Air  Force  Flight  Dynamics  Laboratory,  WPAFB,  Ohio. 


Scope 

The  emphasis  of  this  thesis  is  on  the  development  and 
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examination  of  a formal  methodology  to  perform  evaluations 
of  existing  computer  systems.  The  IMLAC  system  is  used  to 
illustrate  an  application  of  this  technique,  and  to  measure 
the  effectiveness  and  feasibility  of  employing  the  approach 
to  a "real  world"  problem.  Thr  results  of  the  IKLAC  evalu- 
ation are  presented  to  the  users  of  the  system  as  a set  of 
recommendations  and  modifications. 


Approach 

Chapter  II  contains  background  information  about  sev- 
eral different  structured  analysis  techniques  available,  and 
outlines  the  proposed  structured  approach  for  evaluating 

■ 

existing  systems.  Chapter  III  describes,  in  detail,  the 
different  steps  of  the  analysis  technique,  and  applies  these 
to  the  IKLAC  system.  A brief  history  of  the  IKLAC  PDS-4 
system  is  provided  as  background  of  the  system  to  be  evalu- 
ated. Chapter  IV  consists  of  a summary  of  the  results  ob- 
tained from  this  study. 
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II.  Background 


Structured  Analysis 

Accurately  def?  led  system  requirements  are  imperative 
to  a successful  system  development.  The  process  of  esta- 
blishing these  specifications  is  termed  the  requirements 
definition  phase  of  the  development  cycle,  and  encompasses 
all  aspects  of  the  developmental  process  prior  to  the  actual 
design  of  the  system  (Bef  9:6).  Failure  to  adequately  specify 
the  requirements  can  result  in  increasingly  expensive  correc- 
tions at  later  stages  of  development  (Bef  2:5-6). 

Currently,  requirements  are  generated  in  free-form 
English  using  a combination  of  ad  hoc  manual  analysis  and 
common  sense  (Bef  2:5).  Several  problems  that  arise  using 


this  method  are  (Bef  4:10-13): 

1.  Communication.  The  relationship  between  a user 
and  analyst  is  complicated  by  the  lack  of  common 
language,  and  by  the  inherent  difficulty  in  des- 
cribing a non-physical  object. 

2.  Changing  requirements.  The  user  requirements 
change  frequently  as  the  user  becomes  more  aware 
of  what  capabilities  are  available. 

3.  Lack  of  tools.  The  only  tools  available  to  the 
analyst  are  paper,  pencil,  and  his  mental  ability. 

4.  Problems  of  documentation.  Managing  the  enormous 
amount  of  text  required  to  describe  a comolex 
system  is  a major  problem  in  requirements  analysis. 

5.  Work  allocation.  A large  comnlex  mroblem  does  not 
normally  divide  into  equivalent  work  efforts. 

6.  Politics.  The  introduction  of  a new  system  is 
often  associated  with  management  prejudices  and 
power  struggles. 


Several  techniques  have  been  developed  to  deal  with 
these  problems.  One  major  area  of  study  is  in  the  use  of 
automated  tools  to  specify  and  analyze  requirements.  The 
ISDOS  system  is  one  such  tool  which  incorporates  a problem 
statement  language  (PSL)  to  reduce  terminology  inconsistencies, 
and  a problem  statement  analyzer  (PSA)  to  cross  check  for 
redundancies  in  specification  (Bef  11).  The  analyst  defines 
the  system  using  the  PSL  which  invokes  strict  interpretation 
of  terms  and  relationships  of  objects.  Several  advantages 
are  offered  by  this  method.  Interim  reports  and  summaries 
oan  be  automatically  produced,  organization  of  information 
is  automated,  and  consistency  and  completeness  are  guaranteed. 
The  development  of  an  extended  version  of  ISDOS  is  being 
sponsored  by  the  Air  Force,  and  is  known  as  GABA  (Bef  12). 

A similar  automated  approach,  known  as  SBEP,  is  being  used  by 
the  US  Army  Ballistic  Missile  Defense  Advanced  Technological 
Center  (BKDATC)  for  real-time  developments  (Bef  1). 

Another  area  of  study  is  the  use  of  metalanguages  to 
state  specifications  (Bef  13:214).  Bestrictions  placed  on 
these  languages  promote  comprehensibility  and  correctness  of 
proof.  Examples  of  such  languages  are  EUCLID,  CLU,  ALPHABD, 
and  the  higher  order  software  (HOS)  axioms. 

SofTech  has  developed  a rigorous  manual  method  for 
requirement  specification  known  as  structured  analysis  and 
design  technique  (SADT)  (Bef  10).  The  central  concept  of 
SADT  is  to  decompose  a problem  into  a series  of  conceptual 
models.  These  models  are  generated  utilizing  the  basic 
building  blocks  of  all  SADT  diagrams,  boxes  and  arrows. 


Boxes  represent  processes  performed  on  data,  and  arrows 
represent  the  data.  A simple  example  is  shown  in  Figure  1. 
For  an  entire  system,  each  process  must  be  represented  by 
a box.  To  facilitate  the  large  number  of  such  processes, 
and  to  promote  readability,  a top-down  structured  decompo- 
sition is  used  for  the  entire  system.  That  is,  the  entire 
system  is  initially  represented  as  one/activity  box.  A 
second  level  will  decompose  this  activity  into  5-7  sub- 
activities. Each  of  these  will  be  further  decomposed,  and 

so  forth,  until  the  entire  system  is  modeled  to  the  desired 

j 

level  of  detail.  Figure  2 shows  this  decomposition  graph- 


ically (fief  10:2-3). 

Advantages  of  this  method  are  its  readability,  modu- 
larity, and  structure.  It  provides  a straight  forward 
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step-by-step  procedure  for  breaking  a problem  into  a series 
of  sub-parts  with  well  defined  interconnections. 

De  Marco  has  developed  a similar  manual  method  known 
as  structured  analysis  (2ef  4).  This  technique  also  uses 
hierarchal  models  called  "data  flow  diagrams"  (DFD*s).  These 
are  identical  to  the  SADT  models  in  concept,  but  with  dif- 
ferent building  blocks.  Instead  of  boxes  to  represent  pro- 
cesses, structured  analysis  uses  bubbles.  The  elements  are 
shown  graphically  in  Table  I . The  model  similarity  is  such 
that  De  Marco  describes  SADT  as  "...data  flow  diagram  with 
square  bubbles."  (Bef  4:48).  The  final  output  of  structured 
analysis  is  a "target  document"  consisting  of  DFD's,  a data 
dictionary  defining  file  compositions,  and  structured  English. 

Structured  analysis  is  normally  employed  as  a means  to 


U 


t 

I 

t 


» 

* 





- vs  - ' " 


TABLE  I 

Structured  Analysis  Building  Blocks 


Symbol 

Name 

Description 

o 

Bubble 

Process  performed  on 
data 

4 

Data  Flow 

Data  item 

File 

Data  storage 

Source/Sink 

Place  where  data  orig- 
inates or  terminates 

And/Or 

Belational  operators 
on  data 

specify  requirements  for  a new  automated  system.  The  analysis 
is  divided  into  seven  component  studies  (Bef  4:27): 

1.  Study  the  current  physical  environment 

2.  Derivation  of  a jgical  equivalent  of  the  current 
' environment 

3.  Derivation  of  a new  logical  environment 

4.  Determination  of  physical  characteristics  to 
produce  a new  set  of  physical  environments 

5.  Quantification  of  cost  and  schedule  factors 

6.  Selection  of  one  new  physical  environment 

7.  Packaging  the  structured  specification. 

Figure  3 shows  these  components  in  a data  flow  diagram  (Bef 
4:26).  Each  step  will  be  briefly  discussed. 

The  current  physical  environment  that  is  being  studied 
consists  of  the  non-automated  process.  The  analyst  must 
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Figure  3.  Structured  Analysis  Flow 

become  familiar  with  the  flow  of  information  and  output 
products  in  order  to  understand  the  nature  of  the  system. 

The  product  of  this  study  is  a DFD  which  models  the  physical 
system  as  viewed  by  the  user. 

The  next  step  is  to  derive  a logical  equivalent  of  the 
physical  model..  This  is  necessary  to  define  the  logical 
functions  which  are  to  be  performed  by  the  system.  User 
interaction  is  important  here  to  assure  an  accurate  repre- 
sentation of  the  functions  performed.  A logical  DFD  is  the 
output  of  this  effort. 
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Derivation  of  the  new  environment  is  the  user's  op- 
portunity to  specify  what  additional  tasks  or  modifications 
are  desired  of  the  new  system.  A data  flow  diagram  is  pro- 
duced which  totally  defines  the  logical  functions  the  system 
is  to  accomplish. 

At  step  four,  physical  characteristics  and  boundaries 
are  introduced  to  design  several  alternative  physical  models 
of  the  new  system.  These  characteristics  sire  specified  by 
the  user  as  required  physical  limitations.  As  stated,  sev- 
eral alternative  models  are  produced  to  illustrate  physical 
trade-offs. 

Selection  of  one  model  from  the  physical  set  requires 
several  studies  of  costs  and  schedules.  Each  alternative 
must  be  quantified  based  on  the  goals  and  constraints  of  the 
organization. 

The  final  component  of  the  analysis  is  the  packaging 
of  the  documentation  and  specifications.  This  package  is 
necessary  for  the  system  design  phase,  and  represents  the 
main  product  of  the  analysis  portion  of  the  software  life 
cycle. 

Structured  Analysis  as  an  Evaluation  Tool 

Structured  analysis  provides  several  advantages  for 
defining  requirements  of  a new  system.  The  models  provide 
a top-down  logical  overview  of  the  functions  performed. 
Modeling  the  current  physical  system  ensures  that  all  neces- 
sary functions  are  considered,  and  the  seven  steps  provide 
a structured  sequence  of  procedures  to  define  the  require- 
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Several  organizations  possess  existing  systems  which 
may  or  may  not  be  fulfilling  the  requirements  of  the  users. 
Failure  to  meet  these  needs  may  be  a result  of  changing  re- 
quirements or  incomplete  initial  specifications.  In  either 
case,  some  method  is  needed  to  evaluate  the  existing  system 
against  user  requirements.  Several  advantages  afforded  by 
structured  analysis  can  be  applied  to  this  type  of  evaluation. 
Graphic  models  provide  an  easy-to-read  concise  representation 
of  a system.  Modeling  the  system  in  a logical  manner  en- 
courages a functional  evaluation  rather  than  a physical  one. 
Also,  a step-by-step  methodology  promotes  completeness  and 
accuracy. 

The  structured  analysis  procedures  listed  earlier 
cannot  be  applied  directly  to  an  evaluation  effort.  This 
is  a result  of  the  fact  that  the  existing  system  is  already 
automated,  and  is  not  to  be  replaced  by  a completely  new 
system.  However,  several  of  the  same  techniques  and  general 
goals  can  be  used  in  a different  sequence.  The  following 
procedures  are  presented  as  a possible  application  of  struc- 
tured analysis  techniques  to  an  evaluation: 

1.  Logical  modeling  of  the  current  system. 

2.  Logical  modeling  of  the  required  system. 

3.  Recommendations  based  on  model  comparison. 

Each  phase  will  be  discussed  briefly,  and  a detailed  appli- 
cation will  be  presented  in  the  next  chapter. 

Modeling  of  the  current  system  is  the  equivalent  of 
the  first  two  phases  of  structured  analysis.  The  purpose 
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1b  to  become  completely  familiar  with  the  existing  system, 
and  to  model  its  logical  equivalent  in  a data  flow  diagram. 
The  creation  of  a physical  DPD,  as  specified  in  structured 
analysis,  is  not  recommended  for  an  existing  system.  The 
level  of  detail  involved  in  a complex  system  would  result  in 
an  unmanageable  physical  model.  It  is  more  efficient  to 
group  the  system  details  into  logical  equivalents  first,  and 
then  model  the  logical  system.  The  resulting  DPD's  provide 
a framework  for  comparing  the  existing  logical  system  to  a 
required  logical  system. 

The  required  system  model  is  a representation  of  the 
logical  functions  which  the  user  specifies  as  necessary. 

It  is  recommended  that  this  model  be  accomplished  second  so 
that  the  analyst  is  completely  familiar  with  the  existing 
system's  capability  and  limitations  prior  to  interpreting 
user  requirements.  The  existing  model  is  used  as  a guide- 
line for  interviewing  users  as  to  what  functions  should  be 
added  or  deleted.  Modeling  the  required  system  in  the  same 
format  as  the  existing  system  also  promotes  a straight  for- 
ward comparison  of  the  logical  models. 

Comparing  the  two  models  is  a formalization  of  the 
discrepancies  between  the  existing  functions  and  the  required 
functions.  In  this  comparison,  the  analyst  must  decide  if 
additional  functions  specified  in  the  required  model  are 
valid  and  relevant.  The  result  of  this  comparison  is  a set 
of  recommendations  from  the  analyst  to  the  user. 

Por  simplicity,  the  term  "structured  evaluation"  will 


be  used  to  signify  the  methodology  described.  Chapter  III 
presents  cm  in-depth  example  of  applying  structured  evalu- 
ation to  an  actual  system.  The  separate  phases  will  be 
discussed  in  greater  detail,  and  the  associated  problems 
will  be  identified. 


III.  4n  Application  of  Structured  Evaluation 


IMLAC  System 

One  mission  of  the  Analysis  and  Optimization  Branch 
(FBB)  of  the  Air  Force  Flight  Dynamics  Laboratory  is  to 
perform  and  support  structural  analysis.  To  accomplish  this 
mission,  a general  purpose  graphics  computer  was  requested 
in  March  1977  (Bef  5).  As  a result  of  this  request,  an  IMLAC 
PDS-4  computer  and  supporting  equipment  was  leased  in  April 
1977. 

The  IMLAC  system  is  shown  graphically  in  Figure  4 (Ref 
7:4).  It  includes  32  K of  16-bit  memory,  a refresh  vector 
graphics  CRT,  light  pen,  dual  hard  disk  storage,  and  a Ver- 
satec  printer.  The  system  is  capable  of  operating  stand- 
alone for  local  processing,  or  as  a terminal  to  a host  com- 
puter with  a standard  RS-232  interface.  Supporting  software 
consists  of  several  utilities  and  a Fortran  compiler  for 
stand-alone  mode,  and  interfacing  programs  when  used  as  a 
terminal.  A more  detailed  description  of  the  operating 
system  is  presented  as  a user's  guide  in  Appendix  D.  This 
guide  is  a direct  product  of  the  IMLAC  evaluation. 

Justification  for  the  IMLAC  system  by  FBR  was  based 
on  the  specifications  shown  in  Table  II  (Ref  7:5).  The  flick- 
er - free  performance  capability,  available  Fortran,  and  disk 
capacity  were  reasons  cited  for  sole  source  Justification  of 
the  IMLAC  system  (Ref  6). 

Since  the  installation  of  the  equipment,  several  prob- 
lems have  surfaced  resulting  in  limited  use  of  the  system. 


u 


( ) 


•—Interactive  device  options 


"keyboard  ! 

PROGRAMMER/ 

MAINTENANCE 

CONSOLE 

1 

1 

1 

(optional) 

i 1 6* 

I 
I 
I 

, * 

i 

Interface  options 


Ligit  pen  Joystick 

Trackball  Graphic  Mouse 

Data  tablet  Function  keyboards 

Additional  or  special  keyboards 


MAIN 
PROCESSOR  I 


MEMORY 


990 


nsec /cycle 
4 - 64K 
16  bit  word 


Synchronous 
Multiple  asynch. 
Programmable  speed 
select 

Acoustic  coupler 
Nigh  speed  serial 
Three-speed  switch 

Parallel  computer-  -I 
interface  options 


T” 

l 

l 

HP 


options 


DISPLAY 

PROCESSOR 


Memory  options  DP  options 


ROM 

ROM  switch 
Floating  point 
module 


Onivac  AN/UYK-7 
Uni  vac  1230 
Harris  6024/5 
DEC  PDP-11 
DG  NOVA 
DG  ECLIPSE 
HP  2100 

Honeywell  516/716 


I 
I 
I 
I 

* Peripheral  options 

Cassette  storage 
Paper  tape  reader 
Paper  tape  punch 
Magnetic  tape  systems 
Disk  systems 
Floppy  disk  systems 
Disk  share 
Hardcopy 
- Printers 
Plotters 


64K 

Direct  memory 
access 


Circle/arc 
generator 
Scale,  Rotate, 
Trans. Window 
Monitor  control 
interface 
Color  monitor 
interface 


Monitor  options — 1 

15  or  21"  monitor 
Slave  monitors 
Independent  monitors 
Manual  image  control 
Phosphors 
Color  monitor 
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Prospective  users  described  several  problems  including: 

1.  Inadequate  documentation 

2.  Non-standard  Fortran 

3.  Hard-to-learn  procedures 
Confusing  keyboard  strokes 

5.  Incomplete  graphics  capability. 

These  problem  areas,  combined  with  others,  dramatically 
reduced  the  utilization  of  the  system.  At  the  beginning  of 
this  study,  just  one  person  was  using  the  stand-alone  capa- 
bility, and  only  in  a limited  sense.  A few  others  were 
occasionally  exercising  the  TTY  capabilities. 

Modeling  Conventions 

De  Marco's  modeling  technique  is  used  for  representing 
the  systems  in  structured  evaluation.  A brief  discussion  of 
data  flow  diagram  conventions  is  presented  here  for  clarifi- 
cation. 

The  basic  building  blocks  of  DFD's  are  shown  in  Table 

% 

I (page  7).  Bubbles  are  processes  or  functions  that  are  per- 
formed on  data.  Data  flows,  symbolized  by  arrows,  represent 
a path  along  which  information  passes.  The  data  always  flows 
in  the  direction  of  the  arrow.  Sources  and  sinks  are  origi- 
nators and  consumers  of  data.  A file  is  a storage  device  for 
data.  Relational  operators  are  used  when  multiple  data  flows 
enter  or  leave  a bubble.  The  operator  indicates  whether  both 
data  flows  are  necessary  (AND)  or  only  one  (EXCLUSIVE  OR). 

Leveled  data  flow  diagrams  are  a hierarchy  of  DFD's 
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DFD,  and  the  second  number  specifies  which  unique  bubble  on 
the  higher  DFD  is  being  expanded  in  the  lower  diagram.  The 
terms  "parent"  and  "child"  are  used  to  describe  this  relation- 
ship. 

Existing  System  Model 

The  modeling  of  the  IMLAC  system  was  accomplished  in 
four  steps: 

1.  Familiarization  with  the  system 

2.  Identification  of  logical  functions 

3.  Development  of  DFD's 

4.  Verification  of  model  correctness. 

Each  of  these  will  be  discussed  in  detail. 

System  Familiarization.  To  accurately  model  any  com- 
plex system,  it  is  essential  for  the  modeler  to  become  inti- 
mately familiar  with  the  details  of  the  system.  When  the 
system  is  a computer,  this  involves  learning  the  functions 
accomplished  by  the  operating  system,  and  the  algorithms 
used  in  performing  this.  One  means  of  obtaining  this  know- 
ledge is  to  write  several  assembly  language  programs,  and 
perform  modifications  to  the  operating  system.  This  tech- 
nique was  used  with  the  IMLAC.  It  required  several  months 
to  complete  this  phase  of  the  modeling.  To  make  the  effort 
more  productive,  the  programs  and  modifications  attempted 
were  suggested  by  the  users  as  convenient  additions.  Thus, 
information  about  the  system  was  being  acquired  while  providing 
improvements  to  the  system. 
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The  assembly  language  programs  were  written  with  an 
emphasis  on  utilizing  several  available  software  utilities, 
and  interfacing  with  all  peripherals.  For  example,  several 
utilities  were  written  which  used  routines  to  write  to  the 
display  screen,  disk,  printer,  and  TTY  port.  These  assembly 
language  programs  enabled  the  analyst  to  better  understand  the 
operating  system  source  code,  and  gain  insight  into  the  theory 
of  operation  of  the  system.  Modifications  to  the  operating 
system  provided  several  insights  into  the  algorithms  used  to 
perform  system  functions.  Two  such  modifications  completed 
include  variable  size  character  selection  in  the  MONITOR, 
and  improved  print  quality  in  local  graphics.  Several  other 
modifications  were  investigated  which  involved  in-depth 
source  code  study  and  a complete  review  of  available  documen- 
tation. 

Identification  of  Logical  Functions.  To  model  the  log- 
ical equivalence  of  a physical  system,  it  is  necessary  to 
identify  what  logical  functions  are  performed.  A systematic 
approach  was  used  to  determine  these  for  the  IHLAC. 

Initially,  the  names  of  all  operating  system  modules 
were  listed  in  a single  list.  Modules  which  accomplished 
similar  tasks  were  then  grouped  together  with  a description 
of  the  common  task.  The  criteria  which  were  used  to  discern 
similar  tasks  included  common  peripheral  utilization,  and 
analogous  duties  performed.  For  example,  KP,  PK,  MN,  NK, 
and  RENA HE  are  all  modules  which  modify  files,  and  were 


grouped  under  the  heading  of  File  Modification.  Next,  all 
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modules  left  ungrouped  were  considered  for  inclusion  in  an 
existing  group  by  slightly  modifying  the  group  description. 
For  example,  DELETE  was  added  to  the  File  Modification 
group  by  renaming  it  File  Maintenance.  Modules  which  were 
still  ungrouped  were  defined  as  separate  categories. 

The  next  step  in  the  function  identification  is  to 
normalize  the  level  of  abstraction  between  the  different 
groups.  This  is  necessary  to  produce  a list  of  functions 
which  could  be  modeled  at  the  same  leveled  DFD.  To  accom- 
plish this  normalization,  an  iterative  procedure  was  used. 
First,  categories  which  appeared  as  highly  specialized  were 
considered  for  regrouping  with  other  categories  or  parts 
of  other  categories.  If  this  could  not  be  accomplished, 
the  group  was  disbanded,  and  the  modules  were  distributed 
to  other  categories  based  on  their  functions.  Categories 
which  appeared  to  be  too  general  were  considered  for  parti- 
tioning into  separate  categories.  This  process  of  regroup- 
ing and  partitioning  was  continued  until  all  categories 
appeared  to  consist  of  a similar  level  of  abstraction.  The 
final  list  is  shown  in  Table  III.  These  categories  are  the 
logical  functions  to  be  modeled  in  the  data  flow  diagrams. 

Development  of  the  D7D*s.  De  Marco  offers  the  follow- 
ing guidelines  for  developing  DFD's  (Bef  4:63): 

1.  Identify  net  input,  output,  and  data  flows 

2.  Work  outputs  to  inputs,  or  from  the  middle  out 

3.  Label  all  data  flows 

4.  Label  all  bubbles 
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Model 

Reference 


TABLE  III 

IMLAC  Logical  Functions 


Function 


Operating  System 


File  Maintenance 


Local  Graphics 
Host  Graphics 
TTY  Mode 

Disk  Maintenance 


Program  Creation 


Modules 

MONITOR,  SYSLOD, 
ROKLOD,  HAKELG, 
LOGIO,  DIKY, 

DEBUG,  START 

DELETE,  FLUSH, 
FILCOM,  GET,  KN, 
NM,  PK,  KP, 

DIBEKT,  D PRINT, 
PRINT,  RENAME 

TIS4,  SYMBL4 

TIS4,  GTS,  KT'IS 

LINDI,  PSA,  STR14 

COPY,  SAVE,  CHECK, 
SY3TID,  STATUS 

EDITOR,  ASSEMBLER, 
COMPILER,  BINDER 


5.  Ignore  initialization  and  termination 

6.  Omit  trivial  error  paths 

7.  Do  not  show  flow  control 

8.  Be  prepared  to  start  over. 

An  informal  version  of  these  rules  was  used  in  drawing  the 
DFD's  for  each  identified  logical  function. 

First,  the  net  input  and  output  data  items  were  listed 
for  the  logical  function  being  diagramed.  Bext,  all  duties 
performed  by  the  modules  were  listed  under  each  logical 
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heading.  These  duties  were  combined  and  generalized  to  pro- 
duce a summarized  list  of  processes  performed  on  the  data. 

Each  of  these  processes  was  represented  by  a bubble  with 
appropriate  data  flows  drawn  between  them.  It  is  important 
to  note  that  the  separate  processes  within  each  function 
do  not  necessarily  correspond  to  one  particular  program. 

These  processes  represent  a logical  overview  of  the  function, 
and  each  process  may  generalize  several  programs  or  parts 
of  programs. 

To  complete  the  hierarchal  structure  of  the  model,  each 
process,  or  bubble,  had  to  be  further  decomposed  into  a 
second  level  of  detail.  This  was  accomplished  in  a similar 
manner  as  the  high  level  DFD.  A bubble  was  chosen  for  de- 
composition, net  inputs  and  outputs  were  defined,  and  a list 
of  functions  was  generated.  It  was  decided  to  only  model 
two  levels  of  detail  for  this  effort.  This  decision  was  based 
on  the  time  restrictions  for  completing  the  study,  and  the 
belief  that  two  levels  would  provide  sufficient  detail  to 
compare  the  models.  The  complete  model  for  the  IMLAC  system 
is  given  in  Appendix  A. 

Verification  of  Correctness.  It  is  necessary  to  per- 
form several  tests  of  verification  on  a completed  model  to 
ensure  the  accuracy  of  the  representation.  De  Marco  suggests 
the  following  five  checks  (Bef  4:106-112): 

1.  Check  that  all  items  are  labeled 

2.  Check  for  consistency  of  abstraction  level 

3.  Verify  data  conservation 
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4,  Identify  any  file  problems 

5*  Perform  a model  walkthrough. 

The  first  check  is  a bookkeeping  task  to  ensure  model 
completeness.  All  data  flows  and  bubbles  were  checked  for 
proper  labeling,  and  necessary  corrections  were  made. 

Abstraction  consistency  is  a check  that  all  models  on 
the  same  level  contain  the  same  amount  of  detail.  This  con- 
sistency aids  in  readability  and  coherency  of  the  model.  The 
check  was  accomplished  by  verifying  that  all  data  flows  and 
processes  represented  similar  levels  of  abstraction. 

The  term  "data  conservation"  refers  to  the  requirement 
that  all  data  flowing  into  and  out  of  a second  level  DFD  is 
shown  on  the  DFD  from  which  it  is  decomposed,  its  parent. 

In  other  words,  only  data  flows  associated  with  a first  level 
bubble  can  appear  as  inputs  or  outputs  to  its  second  level 
child.  The  only  exception  to  this  rule  is  when  the  data  is 
completely  internal  to  the  process  being  modeled.  Conser- 
vation was  completed  by  comparing  parent  and  child  DFD's, 
and  exceptions  were  noted  in  the  respective  text. 

File  problems  are  characterized  by  such  discrepancies 
as  data  only  flowing  into  a file,  or  inconsistent  data 
flowing  into  and  out  of  a file.  For  the  IHLAC,  these  pro- 
blems required  renaming  some  data  flows. 

A model  walkthrough  is  the  most  time-consuming  of  the 
verification  checks.  Each  model  was  reviewed  by  following 
the  data  from  process  to  process,  and  ensuring  that  the 
diagramed  flow  was  valid.  This  required  checking  the 


r 


23 


documentation  and  source  code  of  the  modules  involved  against 
the  DFD. 

Summary.  The  structured  analysis  model  of  the  existing 
system  represents  a logical  top-down  view  of  the  physical 
IMLAC  graphics  system.  Several  problems  were  associated 
with  the  modeling  process. 

Familiarization  with  the  system  was  the  most  time- 
consuming  phase  with  no  definite  completion  point.  There 
is  no  measurable  criteria  available  to  indicate  when  the 
modeler  knows  the  system  well  enough  to  model  it.  There 
was  also  a delay  in  this  part  of  the  effort  while  the  source 
code  was  being  ordered  and  received  from  IMLAC. 

Identification  of  the  logical  functions  also  lacks 
measurable  criteria  defining  a "good"  portrayal  of  the 
physical  system.  Decisions  were  made  on  a subjective  basis 
with  no  cross  check  available. 

The  development  of  the  DFD's  required  many  decisions 
about,  content,  meaningful  data  and  process  names,  and  ade- 
quate abstraction  levels.  Due  to  the  logical  nature  of  the 
model,  there  was  not  a one-for-one  correlation  of  the  DFD 
bubbles  to  the  IMLAC  software  modules.  This  resulted  in 
generalizations  of  similar  processes  performed  by  several 
different  modules,  and  interpretations  of  the  total  function 
achieved. 

The  verification  checks  were  effective  in  isolating 
several  areas  requiring  further  ref  inement.  However,  as  in 
the  other  phases,  numerous  subjective  decisions  were  necessary 


to  complete  these  checks.  Since  there  were  no  personnel  at 
the  laboratory  familiar  with  the  system  details,  the  final 
model  could  not  be  reviewed  by  a competent  critic.  Thus, 
the  final  model  contains  several  personal  viewpoints  of  the 
system  as  interpreted  by  the  modeler. 


Bequired  System  Model 

To  evaluate  the  system's  performance,  it  is  necessary 
to  have  some  criteria  against  which  to  measure  the  existing 
system.  This  means  there  must  be  some  formal  description 
of  the  system  parameters,  as  defined  by  the  users.  When  a 
non-existing  system  is  being  developed,  such  an  assessment 
of  the  needs  to  be  fulfilled  is  known  as  the  requirements 
definition  (Bef  9:6). 

To  provide  a common  ground  for  comparison,  a model 
of  the  requirements  is  built  similar  to  the  existing  model. 
The  same  techniques  used  for  the  existing  system  model  are 
repeated,  but  with  some  variations  which  will  be  described. 

System  Familiarization.  Since  the  required  system 
does  not  exist  in  a physical  sense,  there  is  no  code  that 
ean  be  studied,  nor  algorithms  to  learn  that  reveal  the 
system  functions.  These  properties  can  only  be  discovered 
by  interviews  with  the  eligible  users  of  the  system.  Some 
information  was  obtained  from  the  initial  request  for  the 
system  (Bef  5),  but  the  specifications  were  too  general  for 
a detailed  model. 

Similar  interviews  were  performed  with  several  users. 
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Initially,  general  questions  were  asked  concerning  how  the 
system  was  to  be  used,  and  what  types  of  capabilities  were 
considered  necessary  to  satisfy  performance  needs.  Following 
these  responses,  more  specific  information  was  requested 
about  the  details  of  the  desired  system.  Emphasis  during 
the  interviews  was  in  terms  of  how  a prospective  system 
might  operate,  not  in  terms  of  the  existing  system. 

Identification  of  Logical  Functions . Data  flow  dia- 
grams are  a logical  representation  of  the  system.  Thus,  as 
in  the  existing  system  model,  it  is  necessary  to  identify 
the  logical  functions  required  to  fulfill  the  users'  needs. 
However,  since  this  model  is  to  be  compared  to  a different 
set  of  DFD's,  it  is  desirable  that  some  degree  of  similarity 
exist  between  the  functional  breakdown  of  the  two  systems. 

If  all  of  the  user  requirements  can  be  interpreted  as  be- 
longing to  one  of  the  existing  model's  functions,  it  is 
advantageous  to  use  the  same  set  of  logical  functions.  This 
set  of  functions  provides  a direct  means  of  comparing  the 
two  models  and  an  initial  framework  for  modeling  the  required 
system  based  on  the  existing  system.  For  this  study,  the 
existing  functions  were  sufficient  to  incorporate  the  user 
requirements  and  were  used  for  the  DFD's.  This  sufficiency 
was  determined  from  user  interviews  concerning  the  general 
goals  and  usages  of  the  desired  system. 

Development  of  the  DFD ' s . The  procedures  used  for 
generating  the  diagrams  followed  the  same  sequence  as  for  the 
existing  system  model. 
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First,  net  inputs,  outputs,  and  processes  were  identi- 
fied, This  involved  interpreting  the  user  supplied  infor- 
mation in  relation  to  the  responsibilities  normally  accom- 
plished by  each  logical  function.  Unless  the  user  speci- 
fically indicated  some  capability  or  function  different  from 
the  existing  system,  the  appropriate  DFD  from  the  existing 
system  was  assumed  to  be  sufficient.  Where  differences 
existed,  the  desired  system  was  drawn  using  the  procedures 
outlined  in  the  existing  system  section.  In  several  in- 
stances, this  resulted  in  simply  adding  extra  bubbles  to 
the  existing  diagram. 

The  completed  model  is  shown  in  Appendix  3,  To  avoid 
repetition,  those  DFD's  identical  to  the  existing  system 
model  were  not  redrawn.  These  are  identified  in  the  asso- 
ciated text. 

Verification  of  Correctness.  The  five  verification 
checks  described  earlier  were  also  applied  to  the  required 
system  model.  The  first  four  were  completed  in  an  identi- 
cal manner  as  for  the  previous  model.  The  walkthrough, 
however,  could  not  be  accomplished  the  same  way,  since  there 
is  no  documentation  or  code  to  compare  with  the  model. 
Ideally,  this  would  be  done  by  having  the  specifying  user 
review  the  model.  However,  such  a review  would  require  the 
user  to  become  familiar  with  the  modeling  structure  and 
protocol.  Within  this  study,  the  primary  users  were  con- 
strained in  the  time  available  to  learn  the  modeling  struc- 
ture, so  a simpler  approach  was  taken.  Each  functional  DFD 
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was  reduced  to  a narrative  description,  and  verbally  confirmed 
with  the  user  as  accurate.  Any  discrepancies  or  changes  were 
incorporated  into  the  DFD. 

Summary;.  The  requirements  definition  model  provides  a 
concise  description  of  a required  system  in  a format  compatable 
to  the  existing  system  model.  The  development  of  this  model 
presented  a different  set  of  problems  than  those  described  for 
the  existing  system  model. 

Attempting  to  extract  useful  information  from  the  user 
was  perhaps  the  greatest  challenge.  It  was  difficult  to  get 
the  user  to  talk  in  terms  of  functional  capability  rather 
than  specific  ohysical  desires.  Another  problem  encountered 
was  similar  to  the  "second-system  effect"  as  described  by 
Brooks  (Hef  3:55-58).  Users  tended  to  view  the  existing 
system  capabilities,  and  suggest  several  "frills"  to  add  on. 

Problems  with  the  development  of  the  DFD's  were  similar 
to  those  for  the  existing  system.  Several  subjective  decisions 
were  necessary  to  complete  the  model. 

The  described  walkthrough  procedure  resulted  in  some 
communication  problems.  The  user  was  unable  to  understand 
all  concepts  explained  in  a DFD  narrative  description.  Several 
specific  ideas  in  the  DFD  had  to  be  expanded  before  a ques- 
tionable point  could  be  resolved. 

The  completed  model  represents  a system  that  would 
satisfy  the  user  requirements.  The  next  stage  of  the  eval- 
uation is  to  comoare  this  model  with  the  existing  system. 
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Comparison  of  the  Models 

The  purpose  of  structured  evaluation  is  to  provide  the 
user  of  an  existing  system  with  a set  of  recommendations  for 
improving  the  effectiveness  of  the  system.  These  recommen- 
dations are  based  on  a comparison  of  the  existing  model  and 
the  model  of  the  required  system. 

Data  flow  diagrams  are  a functional  decomposition  of 
a system.  Attempting  to  compare  two  such  models  is  meaningless 
unless  there  exists  some  similarity  in  the  functional  break- 
down of  the  two  systemSi  Although  the  defined  functions  do 
not  need  to  be  identical,  the  required  system  should  be  either 
a subset  or  superset  of  the  existing  system.  This  provides 
for  comparison  of  similar  functions,  deletion  of  existing 
functions  which  are  not  required,  and  addition  of  new  functions 
not  already  existing.  The  only  difference  in  the  functional 
breakdown  of  the  two  IKLAC  models  is  the  lack  of  a Disk  Main- 
tenance function  in  the  required  system.  This  is  a result 
of  no  user  defined  differences  from  the  existing  system. 
Procedures  for  completing  the  comparison  will  be  briefly 
discussed. 

The  first  step  in  comparing  the  two  logical  models  is 
to  select  a function  and  review  the  first  level  DFD's  for  any 
differences.  Since  the  first  level  DFD's  represent  a general 
overview  of  the  function,  differences  at  this  level  usually 
indicate  a discrepancy  in  the  concept  of  the  function.  That 
is,  either  the  function  is  not  complete,  or  the  function 
contains  procedures  which  may  be  contrary  to  the  requirements 
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of  the  user.  The  Host  Graphics  function  (Diagram  5 in  Ap- 
pendix B)  of  the  required  system  is  an  example  of  this  type 
of  discrepancy.  The  function  has  been  expanded  in  this  model 
to  include  software  routines  on  the  host  machine.  All  dis- 
crepancies in  the  first  level  decomposition  should  be  marked 
for  consideration  in  the  second  level  review.  Examples  of 
such  differences  include  changed  data  flows  and  additional 
outputs. 

The  second  step  in  the  model  comparison  is  to  sequen- 
tially select  and  review  all  second  level  decompositions  of 
the  chosen  function.  The  corresponding  DFD's  should  be  checked 
for  any  discrepancies,  and  noted  accordingly.  It  is  important 
to  consider  differences  imposed  by  changes  in  the  high  level 
parent.  Differences  at  the  second  level  indicate  a discrepancy 
in  the  realization  of  a function  rather  than  in  the  concept. 

For  example,  in  Diagram  1.1,  both  models  depict  the  concept 
of  interpreting  user  commands.  The  required  system  delineates 
between  regular  commands  and  special  purpose  commands. 

After  all  second  level  DFD's  have  been  reviewed,  the 
third  step  in  the  comparison  process  begins.  All  noted  dis- 
crepancies for  the  selected  function  must  be  reviewed  for  their 
relevancy,  and  meaningful  recommendations  generated.  An  ir- 
relevant discrepancy  is  one  that  does  not  affect  the  operation 
of  the  system.  For  example,  the  Operating  System  function 
(Diagram  1)  shows  a file  and  data  flow  discrepancy.  However, 
this  particular  difference  is  only  in  the  existing  system  im- 
plementation, and  has  no  effect  on  the  desired  capabilities 
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of  the  required  system.  Thus,  it  is  disregarded  for  recom- 
mendation. Another  type  of  irrelevant  difference  is  an  added 
capability  which  in  actuality  exists  in  a different  form.  For 
example,  Diagram  2.4  shows  an  added  capability  of  multiple 
file  deletions  as  a comparison  difference.  This  capability 
exists  in  the  actual  system,  but  failed  to  show  up  in  the 
model  because  it  requires  a combination  of  manual  file-naming 

conventions  with  the  automated  capability.  Such  irrelevant 

* 

discrepancies  can  be  a result  of  deficiencies  in  the  model,  or 
of  a lack  of  understanding  about  the  system  capabilities  by 
the  user.  Several  such  differences  are  avoided  when  the  re- 
quired model  is  created  by  explaining  to  the  user  how  different 
features  can  be  implemented  on  the  existing  system. 

Deriving  meaningful  and  useful  recommendations  from  a 
set  of  discrepancies  is  a difficult  task.  Several  consider- 
ations must  be  accounted  for  in  suggesting  improvements  to  the 
existing  system.  Two  such  considerations  are:  the  feasibility 
of  the  recommendation,  and  the  resources  available  to  the  user 
to  accomplish  the  recommendation.  There  is  no  set  sequence 
of  procedures  to  develop  recommendations  from  the  comparison 
discrepancies.  To  organize  the  recommendations,  three  cate- 
gories are  used:  hardware,  software,  and  procedural. 

Hardware  recommendations  are  based  on  expanded  capa- 
bilities to  facilitate  desired  improvements.  An  example  is 
the  addition  of  an  in-office  host  minicomputer  to  resolve 
host  graphic  requirements.  Software  recommendations  include 
specific  programs  to  be  developed  and  modifications  to  some 
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existing  utilities.  Procedural  suggestions  encompass  docu- 
mentation, system  operating  policies,  and  other  aspects  of 
management. 

The  complete  set  of  discrepancies  and  associated  recom- 
mendations for  the  IMLAC  is  presented  in  Appendix  C.  These 
lists  are  a direct  result  of  structured  evaluation,  and  are 
presented  to  the  Evaluation  and  Optimization  Branch  of  the 
Air  Force  Flight  Dynamics  Laboratory  for  consideration. 
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IV.  Conclusions 
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Summary 

Several  software  engineering  techniques  are  available 
to  define  system  requirements  in  a life  cycle.  The  advantages 
achieved  by  these  techniques  are  desirable  in  an  evaluation 
of  an  existing  computer  system.  To  realize  these  advantages, 
a variation  of  De  Marco's  structured  analysis  methodology  is 
developed  for  application  to  an  existing  system.  This  derived 
technique,  known  as  structured  evaluation,  is  applied  to  an 
IMLAC  PDS-4  graphics  system  for  illustration.  Structured 
evaluation  consists  of  three  phases:  current  system  model, 
required  system  model,  and  model  comparison. 

The  current  system  model  is  a graphical  representation 
of  the  functions  performed  by  the  existing  system.  The  mod- 
eling format  is  identical  to  the  structured  analysis  technique, 
and  consists  of  a series  of  decompositions,  called  DFD's, 

which  depict  the  functional  system  in  increasing  detail. 

% 

Modeling  is  accomplished  in  four  stages : system  familiarization, 
function  identification,  DPD  development,  and  model  verifi- 
cation. The  IMLAC  model  contains  two  levels  of  abstraction, 
and  is  shown  in  Appendix  A. 

The  required  system  model  is  similar  to  the  current 
model,  but  represents  system  requirements  as  defined  by  the 
user.  The  same  four  modeling  stages  are  repeated  for  model 
creation,  but  with  different  methods  of  implementation. 
Familiarization  is  performed  through  user  Interviews  about 
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desired  capabilities,  mission  requirements,  and  existing 
problems.  The  same  logical  functions  are  used  for  both  models 
in  this  study  to  enhance  comparison  and  provide  a framework 
for  interpreting  user  requirements.  The  required  IKLAC  model 
is  also  restricted  to  two  levels  of  detail,  and  is  shown  in 
Appendix  6. 

Model  comparison  is  a procedure  of  defining  discrep- 
ancies between  the  existing  and  required  models.  This  pro- 
cedure is  accomplished  through  a systematic  review  of  the 
corresponding  function  DPD's.  Besulting  conflicts  must  be 
inspected  to  isolate  deficiencies  in  the  existing  system. 
Possible  solutions  to  the  discovered  deficiencies  are  examined 
in  regard  to  available  resources  and  feasibility.  A set  of 
discrepancies  and  recommendations  for  the  UUAC  is  presented 
in  Appendix  C. 

Observations 

Modeling  the  existing  system  in  structured  diagrams 
proved  an  effective  tool  for  learning  the  entire  system.  All 
aspects  of  the  operating  system  had  to  be  thoroughly  investi- 
gated to  complete  the  model.  Any  areas  which  were  not  as 
well  understood  became  immediately  obvious  when  modeling  that 
particular  aspect.  Examining  the  system  details  as  the  model 
progressed  provided  a sequenced  approach  to  investigating  the 
entire  system.  This  structure  supplied  a framework  for  ac- 
complishing the  enormous  task  of  learning  an  entire  operating 
system. 

Definition  of  logical  functions  forced  the  analyst  to 
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view  the  existing  physical  system  at  an  abstract  level. 

This  provided  an  understanding  of  the  relationships  between 
individual  components  and  of  the  global  structure  of  the 
system.  An  example  of  this  viewpoint  is  illustrated  in  the 
developed  user's  guide  in  Appendix  D.  The  system  is  viewed 
as  a series  of  functional  areas  rather  than  individual  pro- 
grams. Generation  of  these  functions  was  not  a straight 
forward  procedure,  but  required  several  redefinitions. 

Although  a goal  of  the  defined  functions  is  to  maintain  a 
common  level  of  abstraction,  this  could  not  be  easily  dis- 
cerned until  the  actual  modeling  began  and  details  were  in- 
vestigated. Thus,  it  is  possible  to  discover  after  completing 
several  DPD's,  that  the  functional  breakdown  is  not  satis- 
factory, and  the  effort  must  be  restarted. 

Modeling  the  existing  system  with  only  one  analyst 
created  a problem  in  model  accuracy.  Several  decisions  were 
arbitrary  in  nature  based  on  personal  interpretation  of  the 
functions.  Since  no  other  person  could  verify  these  decisions, 
there  was  no  cross  check  for  accuracy.  Having  only  one  analyst 
resulted  in  another  disadvantage  concerning  the  value  of  the 
final  model.  The  model  is  a concise  representation  of  the 
system  and  could  be  a useful  tool  for  documenting  the  flow  of 
the  system,  but  only  to  someone  familiar  with  the  modeling 
technique.  Since  the  users  of  the  system  have  no  training 
in  understanding  the  model,  several  possible  advantages  are 
lost. 

Modeling  the  required  system  was  simplified  by  using 
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the  same  functional  descriptions  for  the  system.  Interviews 
were  conducted  using  the  existing  model  as  an  initial  guide 
for  questions.  Development  of  the  DFD's  started  with  the 
existing  diagrams  as  an  initial  position  and  modified  them 
accordingly.  In  several  instances,  the  existing  system  DFD 
was  assumed  sufficient  to  describe  the  required  function, 
and  the  DFD  was  used  intact. 

Extracting  complete  and  useful  information  from  the 
users  was  the  greatest  challenge  in  building  the  required 
system  model.  Often,  a desired  capability  which  already 
existed  in  one  form  or  another  was  expressed  as  a needed 
requirement.  Also,  users  tended  to  talk  in  terms  of  specific 
physical  desires  rather  than  functional  requirements.  As 
in  the  existing  system  modeling  process , several  interpre- 
tations of  the  function  had  to  be  developed. 

Model  comparison  was  mainly  an  administrative  task. 

The  actual  additional  requirements  were  discovered  as  the 

required  model  was  being  created.  Since  the  existing  model 
* 

was  used  as  a baseline  for  the  second  model,  the  only  items 
which  influenced  changes  were  those  requirements  not  already 
existing,  or  existing  and  not  wanted.  A formal  comparison 
was  mainly  used  as  a check  to  determine  which  of  these  dis- 
crepancies were  valid,  and  which  were  a result  of  errors  in 
the  model  or  user  misunderstanding. 

The  results  of  the  model  comparison  pointed  to  the 
problems  with  the  system,  but  not  to  the  solutions.  Devel- 
opment of  a meaningful  set  of  recommendations  based  on  the 
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discovered  discrepancies  was  an  integral  part  of  the  eval- 
uation, hut  was  not  well  defined.  Although  software  engin- 
eering disciplines  exist  to  generate  designs  from  the  re- 
quirements, these  techniques  do  not  address  the  modification 
of  several  programs  involved  in  one  functional  discrepancy. 
jtecrvmHiiaTnj ftt.i  ms  were  made  in  three  categories  based  on  per- 
sonal observations  of  available  resources,  technical  ability, 
the  political  environment.  These  recommendations  were 
directly  developed  to  assist  in  problems  discovered  from  the 
structured  evaluation  approach. 

flecommendatlons 

Structured  evaluation  can  be  a valuable  tool  for  deter- 
mining a system's  ability  to  satisfy  user  requirements.  The 
methodology  described  can  be  accomplished  in  a series  of 
steps  to  discover  problem  areas.  The  following  recommendations 
are  suggested  as  additions  or  deviations  from  the  described 
process; 

1.  Use  more  than  one  analyst  as  a check  of  interpre- 
tations and  results. 

2.  Use  the  same  functions  for  both  models  as  much  as 
possible.  This  aids  in  comparison  and  model 
generation. 

3.  Train  the  user  in  the  modeling  conventions,  or  use 
a technique  he  is  already  familiar  with.  This 
assists  in  model  verification,  and  provides  a useful 
document  after  the  evaluation  effort. 

4.  Carefully  consider  the  level  and  validity  of  the 
defined  functions  prior  to  modeling  to  avoid  major 
remodeling  efforts. 

The  concepts  of  structured  evaluation  can  be  utilized 
in  other  areas  of  implementation.  Some  possible  applications 
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are  system  familiarization  and  development  verification 
Modeling  is  a powerful  tool  for  learning  a system 


It  also  provides  a concise  functional  representation  of  a 
complex  system.  These  advantages  suggest  the  possibility 
of  using  this  technique  for  gaining  familiarity  with  an  un- 
known system  not  necessarily  being  evaluated.  This  effort 
provides  the  analyst  with  a structure  for  learning  the 
system,  as  well  as  producing  a useful  piece  of  documentation. 
The  model  can  be  used  at  a later  date  for  analysis  of  modi- 
fications, reference  of  system  flow,  and  as  a guideline  for 
other  system  documentation  such  as  a user's  guide. 

Another  possible  application  of  structured  evaluation 
is  as  a tool  for  requirements  definition  ard  subsequent  veri- 
fication of  a new  system  development.  A normal  requirement 
model  of  a non-existing  system  can  be  created  based  on  user 
interviews  and  studies,  as  is  normally  done  in  structured 
analysis.  After  the  system  is  developed,  a similar  model 

can  be  created  of  the  developed  system  to  check  for  discrep- 
% 

ancles  with  the  specified  requirements.  This  process  is  the 
reverse  of  structured  evaluation,  but  results  in  a similar 
comparison.  An  advantage  of  this  "reverse  structured  eval- 
uation" is  that  the  user  interviews  will  not  be  influenced 
by  an  existing  system. 

Structured  evaluation  is  a viable  software  engineering 
tool  to  analyze  existing  computer  systems.  Further  study  is 
needed  to  develop  a structured  approach  for  generating  pos- 
sible recommendations  from  a list  of  model  discrepancies. 
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TEXT: 

The  IMLAC  graohics  system  receives  its  input  from  either 
a terminal  user  or  a connected  host  computer.  The  user  can 
input  commands  through  the  keyboard,  data  switches,  or  light 
pen.  The  host  interfaces  to  the  system  through  a communication 
channel  which  is  connected  via  a telephone  modem.  Output  from 
the  system  is  transmitted  back  to  the  host,  or  to  an  output 
peripheral  such  as  the  display  screen  or  the  printer. 
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TEXT: 

The  normal  user  command  to  the  operating  system  consists 
of  two  portions:  the  name  of  the  file  to  be  executed,  and  some 
specified  optional  parameters.  These  parameters  are  written 
to  a command  file  which  is  read  by  the  program  once  loaded  and 
put  into  execution.  The  file  name  is  used  to  load  the  appro- 
priate file  off  the  disk. 


FILE  NttC 


I ■ 1 INTERPRET  COWMNO 


TEXT: 


Two  basic  functions  are  oerformed  by  the  interpreting 
program  of  the  IKLAC:  accepting  user  incut,  and  displaying 
system  information.  The  information  is  located  in  system 
tables  which  are  built  from  data  stored  on  disk  and  user 
supplied  data.  User  input  is  broken  into  the  two  categories 
described  in  the  operating  system  text.  The  file  name  portion 
is  further  defined  as  either  a system  or  user  file.  This 
breakout  is  necessary  to  create  the  correct  name  of  the  file 
to  be  loaded. 


FILE  INFORWiTION 


PROCRfltl 


| 1 ,3  EXECUTE  FILE 


TEXT: 


Pile  execution  requires  the  determination  of  the  starting 
address  in  memory.  This  is  found  from  information  in  the  file 
which  contained  the  program  or  from  user  supplied  data.  Actual 
execution  simply  involves  placing  the  starting  address  as  the 
current  executing  address. 
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noSTER  FILE 


STORE  FOE 


Pile  storage  requires  several  checks  to  be  accomplished 
prior  to  the  actual  writing  to  the  disk.  If  the  file  is  found 
to  already  exist  by  the  directory  search,  and  the  user  has  the 
proper  permissions,  the  existing  file  must  be  deleted  and  a 
new  file  created  before  the  loaded  file  is  stored.  If  the  file 
is  new,  the  file  is  created  directly.  The  file  creation  involves 
updating  the  system  tables  and  making  the  space  available.  The 
new  file  name  is  then  entered  into  the  file  directory.  For- 
matting the  file  for  writing  may  require  information  provided 
by  the  user. 


TEXT: 

Deleting  a file  requires  the  existence  of  the  file  and 
the  permission  of  the  user  to  modify  it.  Once  eliminated,  the 
file  information  is  used  to  update  the  appropriate  system 
tables  and  directory. 
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DIRECTORY 


2.3  MODIFY  FILE 


TEXT: 

The  modify  command  must  be  validated  to  ensure  only 
authorized  changes  are  made.  The  standard  directory  and  per- 
mission checks  are  made  for  the  file.  The  actual  modification 
is  only  on  the  directory  entry,  such  as  a nsme  change,  or 
permission  update.  The  new  entry  is  writte®  to  the  directory. 
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INFORMATION 
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extract 

TABLE 
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DISPLAY 

OUTPUT 


2.0  QUERY  FILE  INFORMATION 


TEXT: 

Similar  to  file  modification,  the  querying  of  a file 
only  involves  the  appropriate  directory  entry.  The  query  is 
divided  into  three  types:  on  a specific  file,  on  the  entire 
directory,  or  about  system  information.  For  the  file  request, 
the  information  is  derived  from  the  directory  entry  and  formatted 
for  output.  The  directory  and  information  queries  require 
either  the  entire  directory  or  system  information  tables  to 
extract  the  requested  data.  The  formatted  output  is  sent  to 
the  printer  or  display  depending  on  the  command  issued  by 
the  user. 
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LOCAL  GRAPHICS 


TEXT: 

Local  graphics  is  the  process  of  generating  displays 
using  only  the  user  input  and  the  IMLAC  computer.  These  dis- 
plays can  be  created,  displayed,  and  edited.  To  provide  for 
continuous  use,  the  files  can  also  be  stored  to  and  loaded 
from  a disk  file.  A hardcopy  of  the  display  is  also  available. 
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CREATE  CRAPHICS  FILE 
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TEXT: 

To  create  a graphics  file,  the  user  command  is  inter- 
preted as  one  of  six  disolay  instruction  types  shown  is  the 
diagram.  The  appropriate  display  instructions  are  generated 
and  collected  to  produce  the  created  file.  Internal  to  each 
instruction  generator,  user  interaction  may  be  required  to 
complete  the  amount  of  information  needed  for  that  type. 


TEXT: 

Displaying  a graphics  file  requires  the  master  display 
list  be  updated  based  on  created  or  loaded  files.  The  master 
list  is  either  executed  by  the  display  processor  or  not,  de- 
pending on  the  user  command. 
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3.4  EDIT  GRAPHICS  FILE 


TEXT: 

Several  types  of  graphic  editing;  are  available  to  the 
user.  Each  of  these  require  that  the  desired,  portion  of  the 
display  to  be  edited  is  specified  by  the  user.  The  display 
Instructions  associated  with  this  portion,  or  structure,  are 
then  modified  to  create  the  desired  change. 
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STORE  GRAPHICS  FILE 


TEXT: 

The  output  device  for  disolay  storage  must  be  inter- 
preted as  either  disk  or  plotter.  Storage  to  the  disk  is 
similar  to  the  process  describe  in  2.3  with  the  exception  that 
the  file  must  not  exist  prior  to  the  storage.  Plotting  the 
display  to  the  plotter  is  a hardware  function  initiated  in 
software. 
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TEXT: 

Command  interpretation  is  a straight  forward  task  of 
reading  the  user  input,  and  interpreting  its  function.  Ty 
of  user  input  are  keyboard  and  light  pen. 


Host  graphics  is  the  process  of  developing  displays 
from  commands  issued  by  a connected  host  computer.  The 
functions  performed  are  similar  to  local  graphics  except  for 
loading  and  storing  complete  displays  and  the  ability  to 
query  the  graphics.  Information  obtained  from  these  queries 
is  sent  back  to  the  host  machine. 


TEXT: 

The  creation  process  is  similar  to  the  same  function  in 
the  local  graphics  diagram,  3.2.  The  only  added  capability 
is  the  axis  command  which  draws  an  x.y  axis. 


TEXT: 

Allowing  the  user  to  supply  information  to  the  host 
from  graphic  queries  is  a central  theme  for  interactive 
graphics.  Utilizing  the  different  means  shown  in  the  diagram 
the  user  can  provide  the  host  with  a source  of  input  based 
on  visual  interpretation  of  data  results. 


TEXT: 

Editing  host  graphics  differs  from  the  local  capability. 
The  only  functions  provided  are  adding  or  deleting  defined 
subpictures.  The  other  functions  listed  in  diagram  3.^  must 
be  accomplished  at  the  host  with  a new  structure  created. 
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5.  TTY  nODE 


TEXT: 

TTT  mode  is  the  means  for  communicating  with  a host 
time  sharing  system.  Information  from  the  host  is  interpreted 
using  specified  parameters  from  the  user.  These  parameters 
define  the  type  of  communication,  data  format,  and  whether 
to  display  the  input  or  put  it  directly  to  a file.  The  user 
input  is  separated  into  parameter  definition,  local  commands, 
or  normal  input  to  be  sent  to  the  host.  Using  local  commands, 
the  user  can  send  or  receive  entire  files  of  data. 
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TEXT: 

Several  parameters  can  be  defined  by  the  user  as  illus- 
trated in  the  diagram.  These  parameters  are  used  to  interpret 
different  data  formats  and  set  transmitting  characteristics. 
The  requested  parameter  change  is  displayed  for  the  user. 
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The  host  input  is  read  and  interpreted  using  the  par- 
ameters set  by  the  user.  Depending  on  whether  the  user 
specified  the  incoming  data  as  file  information  or  not,  the 
input  is  either  written  into  an  II1LAC  file  or  displayed  on 
the  screen. 
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5.3  INTERPRET  USER  INPUT 


The  user  input  is  interpreted  as  one  of  four  types, 
normal  input  is  correctly  formatted  and  sent  to  the  host. 

Two  types  of  file  commands  are  recoppiized  to  send  and  receive 
entire  data  files.  The  fourth  input  type  is  to  modify  the 
user  specified  parameters. 


TEXT: 

Host  information  which  is  not  written  to  a file  is 
displayed  on  the  CBT.  The  input  must  be  interpreted  to  be 
printable  and  defined  as  display  instructions  to  add  to  the 
existing  display  list.  The  display  is  constantly  refreshed 
to  remain  visible. 


SEND  D1UK  FILE 


When  an  IMLAC  file  is  sent  to  the  host,  the  user's 
permission  to  send  the  file  must  be  validated.  The  file  is 
then  read  into  memory  a sector  at  a time.  The  sector  is 
transmitted  a byte  at  a time  after  proper  formatting. 
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TEXT: 


Normal  user  inuut  is  disolayed  on  the  screen  along 
with  being  transmitted  to  the  host.  The  input  must  be  for-  | 

matted  correctly  before  transmission.  | 


Disk  maintenance  is  divided  into  the  four  functions 


shown  in  the  diagram.  Physical  disk  cartridges  used  as 


input  or  output  are  shown  as  a source  or  sink  for  the  data. 


The  disk  copy  command  contains  the  source  and  destin- 
ation disk  drive  for  the  copy.  The  cartridges  on  these 
drives  are  validated  for  user  permission  to  modify.  The  disk 
is  copied  a sector  at  a time  with  errors  displayed. 


Disk  checkins:  is  a series  of  sector  reads  to  determine 
if  any  error  statuses  occur.  Another  check  is  that  the 
amount  of  occupied  space  on  the  disk  agrees  with  the  sector 
occupied  table  contained  in  a file  on  the  disk.  Errors  from 
this  comparison  or  from  the  read  are  reported  to  the  user. 


TEXT: 

Modifying  a disk  ID  is  accomplished  in  two  steps. 
First,  the  user's  permission  is  validated  and  the  current 
ID  is  displayed.  Next,  the  user  enters  any  changes  to  the 
current  ID  which  are  used  to  format  the  new  ID  and  written 
to  the  disk. 


PROGRArt  creation 


Program  creation  refers  to  the  generation  of  executable 
object  code  from  either  a high  order  language  or  assembly 
language.  The  four  steps  in  accomolishing  this  task  are: 
creating  the  source  file,  compiling  the  source  if  it*s  a 
high  order  language,  assembling  the  assembly  code,  and  linking 
the  file  to  the  proper  routines. 


TEXT: 

Editing  a program  file  creates  a new  file  if  it  did  not 
exist  before,  or  modifies  an  existing  file.  The  user  command 
specifies  whether  to  load  a file  into  memory  for  editing,  add 
to  the  file  in  memory,  or  modify  the  file.  The  final  version 
of  the  file  is  stored  to  the  disk. 
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COMPILE  FILE 


Fortran  statements  are  separated  into  the  seven  types 
shown  in  the  diagram  for  compilation  purposes.  Each  type 
generates  the  appropriate  assembly  code  to  perform  the  state 
ment.  This  code  is  collected  into  one  assembly  file  and 
stored  to  the  disk. 
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TEXT: 

The  assembly  process  is  done  in  three  passes.  Each 
statement  is  read  for  correct  syntax  and  symbols  to  build 
the  symbol  table.  The  machine  code  is  generated  in  either 
an  object  or  relocatable  format  depending  <om  the  user  speci- 
fications. Object  code  is  complete  and  ready  for  execution 
while  relocatable  code  must  be  linked  with  separate  routines 
to  satisfy  external  references. 
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BIND  FILE 


The  binding  process  is  for  linking  separate  routines 
to  the  main  machine  language  program  to  create  executable 
object  code.  The  user  specifies  the  name  of  the  routines 
to  be  linked  together,  and  the  type  of  linking  required. 

The  symbol  table  for  each  routine  is  updated  to  reflect  the 
eorrect  addresses,  and  the  object  code  is  generated  using 
this  updated  table.  The  final  object  code  is  stored  for 
later  use. 


. _ . 


TEXT: 

The  desired  graphics  model  represents  the  user's  view- 
point of  the  requirements  for  a graphics  system.  These  re- 
quirements are  based  on  the  particular  application  of  the  user. 
The  input  and  output  to  the  system  are  the  same  as  for  the 
existing  system;  host  and  terminal  user  inputs,  and  host  and 
peripheral  outputs.  The  remainder  of  the  system  is  modeled 
following  the  same  functional  division  as  the  existing  system. 
The  disk  maintenance  function  was  omitted  since  no  difference 
was  specified  from  the  existing  model.  Within  each  function, 
activities  which  are  identical  to  the  existing  activity  are 
not  decomposed  to  the  second  level.  These  will  be  specified 
in  the  associated  function  text. 
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EXECUTING 


SYSTEM 

FILE 


TEXT: 

The  user  command  to  the  operating  system  is  interpreted 
as  a file  name  to  be  executed.  The  file  is  loaded  from  the 
disk  and  placed  into  execution.  Activities  1.2  and  1.3  are 
the  same  as  modeled  in  the  existing  system  and  are  not  expanded 
here. 





The  user  input  is  interpreted  as  one  of  three  types : 
a file  name  to  be  loaded,  a message  command  , or  a help  command. 
The  message  command  is  used  to  specify  a message  to  be  dis- 
played with  the  normal  system  information.  This  message  remains 
visible  for  all  subsequent  users,  and  provides  a means  to  inform 
system  users  of  any  critical  information  about  the  system.  The 
help  command  displays  a summary  of  available  system  commands 
eliminating  the  requirement  for  users  to  remember  all  command 
J formats.  The  file  name  input  is  the  file  to  perform  the  desired 

; function. 
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TEXT: 

Pile  commands  are  divided  into  the  six  specified  func- 
tions shown.  The  outputs  of  the  different  functions  include 
updated  files,  file  information  for  user  viewing,  or  files 
loaded  into  memory.  Activities  2.4  and  2.7  are  the  only 
bubbles  requiring  decomposition.  Descriptions  of  the  re- 
maining activities  can  be  found  in  the  existing  system  model. 
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DELETE  FILE 


The  first  process  in  deleting  a file  is  to  specify  which 
file(s)  are  affected.  It  is  possible  to  delete  more  than  one 
file  providing  for  a general  "clean-up"  capability.  Multiple 
file  deletions  require  the  specification  of  some  key  associated 
with  each  file  in  the  desired  group.  The  Master  Pile  Directory 
is  searched  for  any  files  containing  this  key,  and  the  file 
entry  is  removed  if  the  permissions  are  valid.  Both  the 
available  space  table  and  directory  are  updated  to  reflect 
the  change. 


Becovering  a file  refers  to  loading  into  memory  all 
parts  of  a file  that  can  be  accessed.  Those  parts  unacces sable 
due  to  hardware  errors  or  incorrect  file  pointers  are  flagged 
with  error  markers  for  user  handling.  Once  loaded,  the  user 
can  restore  the  file  and  resave  it  onto  the  disk. 


Local  graphics  allow  a terminal  user  to  create,  edit, 
and  store  graphic  displays.  Activities  3.3  and  3.5  are  not 
decomposed  to  a second  level.  These  activities  can  be  located 
in  the  IMLAC  system  model. 
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LOMD  GRflmre  FILE 


User  input  specifies  the  file  to  be  loaded  and  the 
location  in  memory  for  loading.  There  is  no  single  format 
required  by  the  file  to  be  loaded.  Assuming  it  contains 
graphic  instructions  in  some  format,  it  can  be  altered  ts 
the  necessary  structure  for  local  processing.  This  enables 
graphic  files  of  several  different  origins  to  be  accessed 
and  modified  in  a local  mode. 
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TEXT: 

The  user  can  specify  several  different  types  of  in 
structions  to  create  graphics.  The  3-D  indicator  allows 
the  user  to  create  the  display  in  three  coordinates.  Ea 
instruction  generator  uses  this  indicator  to  create  the 
proper  commands. 


O 30 
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User  commands  can  be  inputted  by  the  keyboard  or  the 
f a light  pen  menu.  The  menu  lists  the  various  commands 
are  available  for  the  current  mode  of  operation,  and 
ser  chooses  the  desired  item  through  a light  pen  pick. 


ommand  is  then  interpreted 


to  the  appropriate  function. 
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Host  graphics  extend  the  boundaries  of  the  system  to 
include  the  generation  of  the  commands  on  the  host.  These 
commands  are  transmitted  to  the  system,  and  processed  accord 
ingly.  Information  can  be  transferred  from  the  local  system 
by  the  user  through  the  query  function.  Activities  4.2,  4.3 
and  4.5  are  not  further  decomposed.  Their  functions  can  be 
viewed  in  the  existing  system  model. 


| 4.1  HOST  CREATE  PWKTCS  1 


TEXT: 

Several  instructions  are  available  which  are  similar 
to  the  local  graphics  creation.  The  additional  command 
creates  an  x,y  axis  and  plots  a buffer  of  points  for  the  user 
The  generated  instructions  are  displayed  on  the  screen. 
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TEXT: 

Host  graphic  editing  is  identical  to  local  editing. 

The  only  difference  is  the  origin  of  the  commands.  In  local 
graphics,  the  commands  are  issued  by  the  user  at  the  terminal 
while  in  host  graphics,  they  are  generated  by  the  host  com- 
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TEXT: 

Host  commands  are  generated  from  an  executing  program 
on  the  host  coin-outer.  The  program  contains  calls  to  library- 
routines  which  form  the  necessary  graphic  commands  for  the 
local  system  and  transmits  them  to  the  system. 
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Communication  to  a host  time  sharing  system  is  handled 
by  the  TTY  function.  The  user  defines  the  appropriate  par- 
ameters for  the  transmission,  and  oroceeds  to  send  and  receive 
data  with  the  host  machine.  The  user  can  specify  entire  files 
to  be  received  or  transmitted  between  the  local  and  host 
system.  Activities  5.3  and  5.7  are  the  only  bubbles  expanded. 
The  remaining  bubbles  are  identical  to  the  existing  system 
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User  input  is  interpreted  in  a format  like  the 
terminal.  This  format  requires  users  to  only  be  fami 
with  one  set  of  TTY  commands  to  communicate  with  eith 
minal.  The  input  is  interpreted  to  modify  parameters 
to  the  host,  or  specify  file  transmission. 
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Information  destined  for  the  host  is  displayed  on  the 
screen  and  formatted  for  transmission.  The  specified  para- 
meters define  whether  the  information  is  sent  directly  or 
stored  in  a local  buffer.  The  entire  buffer  is  transmitted 
at  one  time  upon  user  request. 
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Objeet  code  for  execution  is  generated  in  four  steps: 
first  creation,  then  compilation,  assembly  into  machine 
language,  and  finally  the  linking  of  external  routines. 

This  sequence  can  be  altered  at  any  step  depending  on  user 
specification.  For  example,  either  a high  order  or  assembly 
language  porgram  can  be  edited,  compilation  can  create  as- 
sembly or  object  code,  and  the  assembly  can  produce  relocatable 
or  object  code.  Only  bubble  7.2  is  decomposed. 


TEXT: 

The  IMLAC  system  model  illustrates  the  comoilation  of 
a file  into  assembly  language.  This  diagram  shows  the  com- 
pilation directly  into  object  code.  The  user  specifies 
which  format  is  to  be  generated  depending  on  the  particular 
application. 


Appendix  C 

IMLAC  Model  Comparison  Besults 


The  results  of  the  structured  evaluation  performed  on 
the  IMLAC  PDS-4-  graphics  system  are  presented  in  two  parts: 
discrepancies  and  recommendations.  The  discrepancies  sum- 
marize by  function  the  differences  found  during  the  model 
comparison  phase  described  in  Chapter  III.  Recommendations 
based  on  this  comparison  were  presented  to  the  FBB  organi- 
zation for  consideration.  These  suggestions  represent  pos- 
sible solutions  to  the  discrepancies. 


Model  Discrepancies 


Each  function  in  the  two  IMLAC  models  were  compared  for 
differences  which  represent  deficiencies  in  the  satisfaction 
of  user  requirements.  These  differences  are  presented  by 
function  with  a brief  description  of  the  associated  require- 
ment as  specified  by  the  user. 

Operating  System 

The  major  discrepancy  found  in  the  operating  system 
function  is  the  addition  of  two  commands  to  the  MONITOH. 

These  commands,  MESSAGE  and  HELP,  are  required  to  encourage 
the  utilization  of  the  IMLAC  system  by  simplifying  system 
operation.  MESSAGE  allows  the  system  manager  to  display 
helpful  information  or  notices  to  all  users  of  the  system. 
HELP  provides  online  command  descriptions  to  permit  an  in- 
experienced user  to  look  up  individual  command  formats  without 
requiring  a search  through  system  manuals. 

Pile  Maintenance 

A file  recovery  option  is  the  only  discrepancy  illus- 
trated in  this  function.  When  a file  is  partially  destroyed 
through  hardware  failure  or  user  error,  it  is  required  that 
some  means  be  available  to  recover  the  portion  of  the  file 
still  intact.  The  destroyed  part  of  the  file  should  be 
marked  for  user  awareness  to  permit  the  rebuilding  of  the 
appropriate  sections. 
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Several  discrepancies  exist  in  the  local  graphic  func- 
tion. The  ability  to  format  files  is  one  difference  in  the 
"Load  Graphic  Pile"  process.  This  capability  represents  a 
requirement  to  use  a graphic  file  from  any  originating  source 
and  be  able  to  perform  local  editing  and  displaying  of  that 
file.  The  current  system  requires  a strict  format  to  perform 
editing,  and  limits  the  type  of  files  that  can  be  loaded  for 
local  manipulation. 

A three  dimensional  capability  is  a discrepancy  in 
both  the  creation  and  editing  of  local  graphics.  The  type 
of  graphic  work  performed  by  the  users  require  the  ability 
to  view  and  modify  images  in  three  dimensions. 

Light  pen  command  specification  is  a requirement  to 
simplify  user  interaction  for  local  image  processing.  This 
capability  eliminates  complex  key  combinations  and  requires 
less  knowledge  about  operating  instructions. 

Host  Graphics 

A major  difference  in  the  host  graphic  function  is  the 
generation  of  graphic  commands  on  the  host  computer.  Command 
generation  is  required  to  eliminate  complex  programming  in 
the  host  program  to  transmit  detailed  command  specifications. 
The  availability  of  automatic  command  generation  permits  more 
general  Fortran  graphic  calls. 

The  ability  to  generate  x,y  axis  and  automatic  point 
plotting  is  a difference  in  the  "Host  Create  Graphics"  process. 
The  need  to  analyze  data  results  quickly  in  a graphic  plot 
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i s the  requirement  for  this  addition. 

Current  editing  capability  is  insufficient  to  satisfy 
the  user  requirement  for  interactive  image  modification. 

The  required  system  illustrates  full  editing  capability 
similar  to  the  local  graphics  commands. 

TTY  Mode 

The  requirement  to  simplify  user  interaction  is  the 
basis  for  the  Hazeltine  command  discrepancy.  By  allowing 
the  user  to  use  the  same  commands  on  both  terminals,  the 
requirement  for  learning  a new  set  of  commands  is  eliminated. 

The  "Send  Input  to  Host"  process  illustrates  a discrep- 
ancy in  sending  a data  buffer  versus  a data  byte.  This 
capacity  allows  for  extensive  screen  editing  prior  to  transfer 
to  the  host  machine,  and  represents  greater  flexibility  in 
host  communication. 

Program  Creation 

Discrepancies  in  the  program  creation  function  deal 
mainly  with  the  compiler  process.  To  increase  speed  and 
simplify  user  interaction,  the  requirement  for  direct  compi- 
lation to  object  code  is  generated.  To  accomodate  users 
familiar  with  BASIC,  the  requirement  is  specified  for  a 
BASIC  compiler. 


IMLAC  Recommendations 
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The  following  set  of  recommendations  is  presented  to 
the  Analysis  and  Optimization  Branch  of  the  Air  Force  Flight 
Dynamics  Laboratory,  V/PAFB,  for  consideration  toward  improving 
the  IMLAC  PDS-4  graphics  system.  These  recommendations  are 
a result  of  an  evaluation  completed  in  partial  fulfillment 
of  the  requirements  for  the  degree  of  Master  of  Science  at 
the  Air  Force  Institute  of  Technology. 

The  recommendations  are  separated  into  three  categories: 
hardware,  software,  and  procedural.  A brief  descriptive  text 
is  included  with  each  recommendation.  The  recommendations 
are  ordered  in  each  category  according  to  the  relative  pri- 
ority within  the  group. 

Hardware 

1.  Acquisition  of  a typewriter  quality  printer.  To 
facilitate  the  use  of  the  flexible  text  editor,  it  is  neces- 
sary that  a high  quality  print  output  be  available.  This 
device  would  encourage  the  use  of  the  systea  for  documentation 
and  report  generation.  Several  devices  compatable  with  the 
IMLAC  system  are  currently  available  commercially. 

2.  Investigation  of  IMLAC  improved  Monitor  CBT.  A 
large  amount  of  graphic  information  being  displayed  results 
in  a detrimental  "flickering"  of  the  screen  image.  This 
problem  is  caused  by  the  time  delay  required  to  refresh  the 
soreen  images  before  the  phosphorous  begins  to  fade.  IMLAC 
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h»g  a CBT  available  which  reduces  this  problem  by  increasing 
the  length  of  time  that  the  screen  phosphorous  remains  active. 
A disadvantage  of  this  device  is  that  it  will  tend  to  produce 
■ghost"  images  during  animation.  Further  analysis  should  be 
performed  to  determine  if  the  IHLAC  device  is  cost  effective 
for  FBE  application. 

3.  Investigation  of  local  host  minicomputer.  The 
acquisition  of  a local  minicomputer  would  satisfy  several 
graphic  requirements  not  currently  satisfied  with  the  IHLAC 
system  such  as: 

- greater  local  computing  power 

- dedicated  host  graphics 

- real-time  interactive  graphics 

- improved  mathmatical  accuracy 

- standard  Fortran  compiler 

However,  the  cost  effectiveness  of  such  a system  is  dependent 
on  the  amount  and  type  of  graphic  work  load  projected  by  the 
FBR  organization.  Studies  should  be  conducted  to  determine 
future  requirements  in  the  area  of  interactive  graphics. 
Existing  conditions  indicate  that  any  acquisition  will  not 
be  effective  unless  substantial  software  and  personnel  support 
is  obtained  with  the  minicomputer.  Examples  of  additional 
support  required  are: 

- in-house  software  expertise  (operating  system,  gra- 
phics, assembly  language,  etc.) 

- interfacing  graphics  software  for  the  IHLAC 

- complete  high  level  language  capability 

4.  Addition  of  memory.  Current  requirements  and  util- 
ization of  the  IHLAC  system  does  not  justify  the  acquisition 
of  the  IHLAC  expanded  memory  option.  Memory  size  is  not  a 
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limitation  in  current  applications.  Expanding  the  utilization 
of  the  IMLAC  system  via  addition  of  a local  host  minicomputer 
will  not  necessarily  create  the  requirement  for  the  extra 
memory.  A reevaluation  of  this  option  will  have  to  be  ac- 
complished at  that  time. 

Software 

1.  Modification  of  Fortran  compiler.  To  promote  util- 
ization of  the  local  processing  capabilities,  it  is  necessary 
that  several  modifications  be  implemented  in  the  Fortran  com- 
piler. Specific  areas  requiring  investigation  are: 

- memory  limitation  on  size  of  subprogram 

- fatal  stack  overflow  problem 

- improved  graphic  calls  (including  light  pen) 

- more  definitive  error  messages 

Currently,  the  FBB  organization  does  not  have  the  technical 
resources  to  accomplish  such  modifications  locally.  The  cost 
of  contracting  out  this  project  should  be  investigated,  or 
an  effort  should  be  directed  at  obtaining  local  software 
expertise. 
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2.  Creation  of  a local  Fortran  library.  Several  util- 
ities can  be  generated  in  a combination  of  Fortran  and  embedded 
assembly  language  code  to  provide  for  better  local  processing 
capability.  These  utilities  can  be  placed  in  a local  library 
available  to  all  Fortran  users.  Possible  routines  include: 

- improved  graphic  calls 

a)  light  pen  calls 

b)  graphic  macros 

c)  automatic  axis  and  plotting 

d)  rotation,  translation,  and  scaling 

- input/output  routines 

a)  standardized  calls 

b)  host  machine  communication 
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o)  peripheral  interfaces 
- mathmatical  algorithms 


3.  Modify  TTY  interface  (LINDI).  Communication 
protocol  should  imitate  Hazeltine  procedures  to  provide 
Tna-riTmnn  utilization  of  the  IHLAC  TTY  capabilities.  (This 
modification  was  completed  in  the  course  of  this  study. ) 

4.  Development  of  Graphics  Compatability  System  (GCS) 
interface.  A three  dimensional  version  of  GCS  is  currently 
available  on  the  CDC  with  an  IHLAC  driver.  Problems  asso- 
ciated with  the  driver  have  made  the  system  unusable,  and 
are  currently  under  investigation  by  the  computer  center. 

Close  scrutiny  of  the  computer  center's  progress  should  be 
continued  to  develop  the  GCS  capability.  This  library  is 
essential  to  the  host  graphic  function  of  the  IHLAC  system. 

5.  Generation  of  operating  system  utilities.  Several 

FDS-4  utilities  can  be  generated  to  assist  in  normal  system 

utilization.  Some  examples  of  desirable  utilities  are: 

% 

- message  line  in  Monitor  (completed) 

- character  size  control  for  utilities  (completed) 

- online  command  summary 

- file  recovery  to  salvage  damaged  files 

- format  conversion  for  local  graphics  (TIS4  format) 

6.  Modification  of  TIS4  for  print /plot.  The  recently 
acquired  capability  of  combined  plotting  and  printer  generated 
characters  on  the  Versatec  printer  provides  an  opportunity 

to  create  local  graphics  with  high  quality  characters.  This 
modification  involves  adding  a new  command  to  the  TIS4  program. 
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7.  Modification  of  local  utility  character  sets. 
PDS-4  modules  contain  character  descriptions  for  displaying 
alphanumeric  information  to  the  display  screen.  Improved 
quality  of  these  characters  when  plotting  to  the  printer  can 
be  obtained  by  redefining  the  strokes  which  generate  the 
characters.  The  SYliBlA  program  can  be  used  to  help  define 
the  new  characters.  (This  effort  has  been  started  in  the 
course  of  this  study,  and  TIS4-  already  has  been  modified. ) 
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8.  Modification  of  text  editor  (JOD).  The  JOD  system 
has  many  useful  attributes  for  text  editing,  but  must  be 
modified  to  generate  reports  in  a more  general  format.  These 
modifications  should  include: 

- specified  location  of  page  numbers 

- selection  of  section  numbering  schemes 

- deletion  of  IMLAC  product  statement 

Some  of  these  changes  can  be  accomplished  by  redefining  the 
editor  macros  used  by  JOD. 

9.  Generation  of  STAGING  driver.  STAGING  is  a graphics 
system  specifically  designed  for  structural  application. 

This  program  is  directly  associated  with  the  mission  of  the 
PBfi  branch  and  represents  a prine  tool  in  the  organization's 
work  effort.  To  incorporate  the  refresh  capability  of  the 
IMLAC  system,  a STAGING  driver  is  needed  to  interface  with 
the  IMLAC.  This  driver  should  be  written  by  a programmer 
familiar  with  the  IMLAC  system. 

Procedural 

1.  Development  of  general  IMLAC  user's  guide.  A 
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summary  of  available  capability  and  introduction  to  the 
documentation  is  required  as  a reference  for  the  IMLAC 
users.  (This  guide  was  completed  in  the  course  of  this 
study. ) ' 

2.  Documented  procedures  for  system  use.  A formal 
set  of  operating  procedures  should  be  generated  and  enforced 
by  the  F3SC  branch.  These  procedures  should  include: 

- log  in  requirements 

- proper  use  of  removable  disks 

- access  to  individual  user  areas 

- log  out  and  shut  down  procedures 

These  procedures  will  protect  users  against  accidental  des- 
truction of  files  and  equipment. 

3.  Class  presentation  of  IMLAC  system.  A formal 
seminar  of  IMLAC  capabilities  and  limitations  should  be 
presented  to  interested  users.  This  seminar  should  be  given 
regularly  for  new  users  as  an  introduction  to  the  system. 

The  information  will  encourage  proper  use  of  the  IHLAC  system. 
* 

4.  Acquisition  of  IHLAC  technical  expert.  Several 
recommendations  have  been  made  concerning  modifications  of 
IMLAC  software  and  creation  of  assembly  code  utilities. 

There  is  sufficient  need  for  an  IHLAC  technical  expert  to 
warrant  a full  time  worker  in  this  position.  Such  an  expert 
oould  provide  technical  advice  to  system  users,  generate 
helpful  utilities  and  modifications,  and  provide  general 
graphic  consultation  to  the  organization. 
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Summary 


The  recommendations  presented  are  based  on  an  analysis 
of  the  current  IMLAC  system  and  perceived  requirements  of 
the  FBB  organization.  A change  in  the  graphic  requirements 
would  necessitate  a reevaluation  of  the  suggested  efforts. 

A suggested  approach  to  implementing  these  recommenda- 
tions is  to  begin  with  the  procedural  category.  These  are 
the  easiest  to  fulfill,  and  will  produce  the  quickest  results. 
The  first  three  recommendations  in  this  section  are  aimed  at 
increasing  user  awareness  concerning  the  capabilities  and 
limitations  of  the  IMLAC  system.  This  awareness  will  result 
in  increasing  system  utilization.  The  acquisition  of  a 
technical  expert  is  essential  to  the  success  of  the  suggested 
software  modifications.  Whether  chis  expertise  is  developed 
with  in-house  personnel  or  with  a new  position,  it  is  critical 
that  some  person  or  group  be  delegated  specific  responsibility 
to  learn  the  IMLAC  system  in  detail. 

The  first  four  software  recommendations  are  the  most 
critical  to  resolve  current  problems.  Immediate  attention 
should  be  directed  to  generate  a useable  Fortran  compiler 
and  to  improve  the  GCS  interface.  These  utilities  are  the 
most  essential  components  for  satisfying  current  user  re- 
quirements. If  a lack  of  expertise  prevents  the  possibility 
of  compiler  modification,  alternative  measures  should  be 
initiated  to  reduce  the  problem.  For  example,  known  problems 
and  ways  of  avoiding  them  should  be  documented  by  those  users 
most  familiar  with  the  Fortran  problems.  The  remaining  soft- 
ware recommendations  represent  more  of  a convenience  than  a 
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direct  requirement 


None  of  the  hardware  recommendations  are  immediately 
required  for  effective  use  of  the  IMLAC  system.  The  type- 
writer printer  would  provide  the  most  immediate  increase  in 
system  utilization.  The  local  host  computer  could  produce 
a great  many  advantages,  but  only  if  the  software  and  per- 
sonnel requirements  are  first  satisfied.  The  needs  for 
technical  expertise  and  strong  software  support  will  increase 
upon  acquisition  of  an  additional  computer. 
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CHAPTER  1 
Introduction 


The  IMLAC  PDS-4  graphics  system  was  leased  in  April 
1977  to  provide  local  computer  support  for  structural  analy- 
sis problems.  This  user's  guide  is  provided  to  aid  in  and 
encourage  utilization  of  the  IMLAC 's  resources. 

The  content  of  this  document  is  a direct  by-product 
of  an  AFIT  thesis  effort  to  evaluate  the  existing  IMLAC  sy- 
stem. The  evaluation  was  performed  by  Capt.  Dennis  L. 
Schweitzer  from  August  1978  to  March  1979.  All  opinions  and 
suggestions  contained  herein  reflect  the  author's  personal 
viewpoint. 

1.1  Purpose  of  Manual 

This  user's  guide  is  designed  as  an  introduction  and 
reference  to  the  functional  capabilities  of  the  IMLAC  sy- 
stem. Each  section  represents  one  functional  aspect  of  the 
system.  An  overview  of  each  function  is  given,  and  the  appro- 
priate programs  and  supporting  documentation  are  listed. 
Limitations  and  problem  areas  are  described  where  appropriate. 

1.2  Manual  Format 

Chapter  2 of  this  manual  provides  an  overview  of  the 
IMLAC  system,  and  is  recommended  reading  for  all  users.  A 
suggested  set  of  operating  procedures  for  normal  system  use 
is  included.  Additional  introductory  material  can  be  found 
in  the  overview  section  of  each  chapter. 

Chapters  3-8  describe  functional  capabilities: 
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Chapter  3 - TTY  Interface 
Chapter  4 - Pile  Creation/Editing 
Chapter  5 - Problem  Execution 
Chapter  6 - Local  Graphics 
Chapter  7 - Host  Graphics 
Chpater  8 - File  Maintenance 


To  effectively  use  this  manual  as  a reference  guide, 
the  following  procedures  are  recommended: 

1.  Find  the  particular  functional  area  of  interest  in 
the  Table  of  Contents. 

2.  Bead  the  overview  of  the  area  to  become  familiar 
with  the  general  philosophy  of  operation. 

3.  Review  the  short  descriptions  of  supporting  pro- 
grams available  for  the  function. 

4.  Refer  to  the  IMLAC  manual  of  operation  for  the  sup- 
porting program  to  be  used.  This  will  provide 
specific  instructions  and  details  of  operation. 


CHAPTER  2 
System  Overview 


2.1  Physical  Characteristics 

The  IMLAC  PDS-4  is  a 16-hit  word  minicomputer  which  in- 
cludes the  following  supporting  hardware: 

- 32K  (decimal) memory 

- 21  inch  refresh  vector  graphics  CRT 

- Dual  hard  disk  mass  storage  (10  million  bytes/disk 
capacity) 

- Versatec  printer/plotter 

- Light  pen 

- Control  console 


Two  processors  are  resident  with  two  separate  supporting 
instruction  sets.  The  display  processor  interprets  display 
instructions  for  controlling  all  screen  activities.  These  in- 
clude vector  generation,  scaling,  rotation,  reflection,  and 
blinking.  These  instructions  reside  in  central  memory  and  are 
accessed  via  memory  cycle-stealing. 

The  main  processor  interprets  and  executes  a standard 
minicomputer  instruction  set.  The  main  processor  controls 
activation  of  the  display  processor  by  means  of  special  in- 
structions. 

The  display  CRT  contains  2048  X 2048  (10)  addressable 
points.  Since  it  is  a refresh  CRT,  screen  images  must  be  re- 
drawn approximately  30  times  a second  to  remain  visible  without 
■flickering".  Hardware  features  for  the  IMLAC  display  include: 

- Circle/arc  generator 

- Blinking 

- Variable  intensity 

- Rotation/reflection 

- Scaling 

- Light  pen 
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The  dual  disks  are  composed  of  one  removable  and  one 
permanent  cartridge.  I/O  is  performed  on  a direct  memory 
access  (DMA)  channel. 

The  Versatec  printer/ plot ter  can  reproduce  screen  images, 
or  it  can  be  used  to  print  alphanumeric  characters.  Dot  ma- 
trices are  generated  via  an  electrostatic  charge. 

For  further  details  on  the  IMLAC's  physical  charater- 
lstics,  refer  to  the  "PDS-4  System  Manual". 
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2.2  Operating  System 

Several  software  utilities  are  provided  to  operate  the 
PDS-4  system.  Those  utilities  which  directly  support  the  de- 
scribed functions  are  summarized  in  the  respective  functional 
chapters.  The  central  operating  system  module,  termed  the 
MONITOB,  will  be  briefly  discussed  here. 

As  the  system  is  initially  powered  up,  a copy  of  the 
MONITOB  is  automatically  loaded  into  memory  and  executed. 

When  the  MONITOB  is  in  control,  the  system  parameters  are 
displayed  along  with  the  word  *command".  The  command  which 
the  user  types  in  will  specify  the  name  of  a file  to  be  exe- 
cuted. The  MONITOB  reads  the  user  input,  loads  the  appropri- 
ate file,  and  passes  execution  to  that  program.  The  loaded 
file  overlays  the  MONITOB  in  memory.  Upon  completion  of  its 
task,  or  by  user  command,  the  executing  file  loads  in  a new 
copy  of  the  MONITOB  from  the  disk,  and  restarts  its  execution. 

To  support  disk  I/O,  a set  of  tables  and  I/O  routines 
remain  permanently  in  core.  This  information  is  reinitialized 
whenever  the  system  is  powered  on. 
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For  further  information  on  the  IMLAC  operating  system, 
refer  to  the  "Disk  Operating  System  User's  Manual". 

2.3  File  System 

IMLAC  files  can  reside  on  either  the  lower  permanent 
disk  (disk-0),  or  on  the  upper  removable  disk  (disk-1). 
Different  removable  disks  can  be  loaded  for  access  to  differ- 
ent files.  Each  file  has  a user  area  associated  with  it. 

These  areas  are  logical  in  nature,  and  do  not  represent  any 
particular  physical  location  on  the  disk.  There  is  no  re- 
striction placed  on  the  amount  of  disk  space  allocated  to  an 
individual  user  area. 

IMLAC  files  have  a permission  value  associated  with 
them.  This  value  specifies  which  user  area  can  access  and 
modify  the  file.  A full  description  is  provided  in  the  "Disk 
Operating  System  User's  Guide". 

Each  file  also  has  a two  letter  extension.  This  exten- 
sion is  used  by  several  utility  programs  to  indicate  in  which 
format  the  file  is  written,  i.e.  Fortran,  object,  data,  etc. 
Files  with  a ".SV"  extension  belong  to  the  operating  system 
should  not  be  modified  or  deleted.  Similarly,  all  files 
In  user  area  1,1  should  not  be  altered. 

2.4  Operating  Procedures 

When  power  is  first  applied  to  the  IMLAC  system,  the 
user  should  make  sure  that  the  proper  removable  disk  is 
loaded.  This  assures  the  user  that  files  to  be  referenced  are 
available.  If  the  user  does  not  intend  to  reference  any 
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existing  flies,  he  should  load  a general  purpose  cartridge, 
or  disk,  as  a precaution  against  accidental  •clobbering"  of 
a removable  disk. 

After  the  disk  "ready"  light  comes  on,  the  user  can 
initialize  the  operating  system.  This  is  accomplished  using 
the  control  console  switches.  First,  the  address  switches 
should  be  set  to  value  40  (octal);  all  switches  except  #10 
should  be  down.  Next,  press  the  stop  button  followed  by  the 
start  button.  This  will  load  in  a copy  of  the  KONITOB,  and 
the  system  parameters  should  be  displayed  on  the  screen. 

The  operator  must  now  specify  which  user  area  and  which 
disk  he  wants  to  define  as  his  primary  source  for  file  access. 
This  is  critical  since  the  operating  system  controls  file 
access  based  on  which  user  area  is  specified.  Any  files 
created  are  automatically  defined  as  belonging  to  this  parti- 
cular user  area  and  disk. 

The  user  area  is  specified  using  the  LOGIN  program. 


The  uper  types  in: 

LO/n,m:p  n,m  = user  area  (examole:  2,3) 

p * primary  disk  (:0,  :1,  or 

:0:1) 

If  the  primary  disk  is  the  lower  disk  (:0),  the  user  can  not 
access  files  on  the  removable  cartridge.  If  the  upper  disk 
is  specified  (:1),  both  upper  and  lower  disks  are  attached  for 
acoess.  When  the  user  specifies  both  disks  (:0:1),  the  first 
disk  is  considered  as  primary,  but  files  on  both  disks  can  be 
used.  All  files  created  are  placed  on  the  primary  disk,  and 
files  referenced  are  searched  for  first  in  the  user  area  on 


the  primary  disk,  then  on  the  secondary  disk. 

When  the  system  is  initialized,  the  user  is  automati- 
cally logged  into  user  area  1,1:0.  Although  normal  operations 
can  he  completed  from  this  area,  it  is  strongly  recommended 
that  the  user  log  into  his  assigned  user  area.  Similarly, 
if  the  system  is  already  initialized,  the  new  user  should 
log  into  the  appropriate  area.  This  prevents  the  possibility 
of  mistakes  that  wipe  out  another  user's  file,  and  ensures 
that  any  created  files  will  belong  to  the  correct  user. 

Upon  completion  of  the  desired  tasks,  the  user  may 
want  to  perform  one  or  more  of  the  following  suggested  pro- 
cedures : 

1.  The  user  should  verify  that  all  files  to  be  kept 
are  located  in  the  correct  area  of  the  removable  disk  (:1). 
Since  the  lower  disk  is  utilized  by  everyone,  it  should  be 
used  only  as  a scratch  pad  to  contain  temporary  or  test  files. 
THEBE  IS  NO  GUARANTEE  TO  ANY  USES  THAT  A FILE -ON  THE  LOWER 
DISK  WILL  REMAIN  INTACT  FOR  ANY  LENGTH  OF  HME1  The  user 
should  move  all  files  to  be  retained  to  the  upper  disk. 

2.  The  user  should  eliminate  unnecessary  or  temporary 
files  from  his  user  area.  This  provides  more  space  on  the 
disk  for  other  users,  and  prevents  saturation  of  available 
space.  This  is  especially  important  on  removable  cartridges 
shared  with  more  than  one  user. 

3.  In  order  to  safeguard  user  files  on  a removable 
disk,  ttie  user  should  remove  the  disk  and  load  a general  pur- 

f ) 

pose  cartridge  for  the  next  user.  This  practice  prevents  the 
general  user  from  accessing  another's  file  area. 


126 


4.  The  final  recommendation  involves  shutting  down  the 
IMLAC  system.  No  special  commands  are  required;  simply  turn 
the  power  off.  Care  should  he  taken  to  stop  the  disk  prior 
to  turning  the  power  off  at  the  wall  switch.  Damage  to  the 
removable  cartridge  could  result  if  the  drive  powers  down 
without  first  being  stopped. 


CHAPTER  3 
TTY  Interface 


3.1  Function  Overview 

Communication  with  a host  machine  is  essential  to  pro- 
vide the  extended  resources  necessary  for  complex  interactive 
graphics.  This  communication  link  allows  the  IMLAC  to  be 
used  as  an  intelligent  terminal.  It  is  intelligent  in  the 
sense  that  the  local  computing  power  can  perform  pre-  and  post- 
processing on  transmitted  information.  This  includes  data 
formatting,  macro  commands,  local  editing,  plus  several  addi- 
tional features. 

Although  the  actual  data  is  sent  and  received  through  a 
hardware  interface,  it  is  necessary  to  have  local  executing 
software  to  interpret  the  input,  run  the  display,  and  format 
the  output.  The  IMLAC  provides  different  programs  (described 
in  the  next  section)  which  perform  these  functions.  The  user 


simply  calls  one  of  these  programs  into  execution,  and  pro- 


ceeds to  connect  the  communication  link  via  the  telephone 
modem.  When  the  host  system  sends  information  through  the 
link,  the  IMLAC  program  reads  the  characters,  displays  them, 
and  waits  for  user  input  from  the  keyboard.  This  input  is 


interpreted  and  sent  to  the  host  when  applicable.  Standard 
TTY  communication  is  achieved  with  the  benefit  of  a local 
program  permitting  improved  performance. 

Communication  is  not  limited  to  any  single  host.  The 
interface  permits  the  user  to  specify  such  parameters  as  baud 
rate,  data  format,  and  type  of  communication.  This  allows  the 
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IMLAC  to  connect  with  any  computer  that  can  be  linked  through 
the  telephone  modem.  However,  it  is  the  user's  responsibility 
to  be  familiar  with  the  host  system's  communication  protocol 
for  intelligent  conversation. 

3.2  Available  Software 
3.2.1  PSA 

PSA  is  a program  which  allows  the  IMLAC  user  to  specify 
communication  parameters.  Baud  rate,  data  format,  and  ter- 
minal type  are  programmable  to  allow  communication  with  sev- 
eral different  host  machines.  PSA  executes  in  a question- 
answer  format.  Table  1 shows  an  example  of  the  PSA  values 
for  GDC  communication.  Befer  to  the  IMLAC  manual  "Disk 
Operating  System  User's  Guide"  for  specific  operating  pro- 
cedures . 


TABLE  1 

PSA  Options  for  Cyber  Communications 


Option 

Value 

Terminal  Type 

A (TTY) 

Send  Baud  Bate 

G (1200) 

Beceive  Baud  Bate 

G (12 &&) 

Data  Format 

D (7/1*0 

Data  Level 

A (8) 
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3.2.2  LINDI 

LINDI  is  the  main  program  for  terminal  communication. 

When  executed,  LINDI  interprets  several  local  commands.  These 
commands  modify  the  transmitting  format,  signify  file  transfers, 
sets  terminal  parameters.  Examples  may  be  found  in  the 
"Disk  Operating  System  User's  Guide".  One  useful  feature  of 
this  program  is  the  ability  to  hold  a communication  link  open. 
When  the  user  is  connected  to  a host  machine,  he  can  terminate 
the  LINDI  program  (keyboard  combination  HEP  and  Q keys),  per- 
form some  IMLAC  local  function,  recall  LINDI  into  execution, 
and  still  have  the  communication  link  with  the  host. 

Prior  to  loading  the  LINDI  program,  the  user  should  check 
to  ensure  that  the  correct  transmitting  parameters  are  set. 

This  is  accomplished  by  running  the  PSA  program,  and  specifying 
the  desired  parameters. 


3.2.3  LIND2 

LIND2  was  created  to  provide  terminal  users  with  more 
capability  and  flexibility  when  using  the  IMLAC  with  a host 
machine.  To  use  this  program,  simply  type  LIND2  while  in  the 
MONITOB  command  mode.  Several  features  have  been  added  to 


the  IMLAC  version  of  LINDI,  and  will  be  discussed  below. 

3. 2 .3.1  PSA  Default  Values 

When  LIND2  begins  execution,  the  following  question  will 
appear  on  the  screen: 

OK  TO  USE  DEFAULT  PSA  VALUES  ? Y/N 


If  the  user  types  Y in  response,  the  following  values  are 
assigned  to  the  interface:  1200  baud  receive  and  send,  7/10 
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format,  and  8 level  data.  These  values  are  based  on  a normal 
CDC  TTY  interface.  If  an  H is  responded,  the  values  are  not 
changed,  and  whatever  was  last  specified  via  a PSA  run  or 
LIHD2  execution  is  used.  Thus,  if  some  value  other  them 
default  is  to  be  specified,  first  run  PSA  and  set  the  appro- 
priate values,  then  run  LIND2  and  respond  N. 

3.2. 3.2  Parameter  Display 

LIND2  displays  several  parameter  values  at  the  top  of 
the  screen  when  executing.  The  parameter  list  is  illustrated 
in  Table  2.  To  erase  this  display  and  allow  the  entire  screen 
for  terminal  use,  strike  the  FOEM  key.  Successive  strikes  of 
this  key  will  toggle  the  display.  To  erase  the  screen  below 
the  parameter  display,  strike  the  TAB  key.  This  also  erases 
the  entire  screen  when  the  parameters  are  not  being  shown. 


TABLE  2 

UHD2  Parameter  List 


A) 

TTY  Port 

B) 

Ho  Parity 

C) 

Pull  Duplex 

D) 

Echo 

E) 

ASCII 

P) 

Display  On 

0) 

Output  File: 

Hone. 

0. 

0 

; 0 

H) 

Input  File: 

Hone. 

0, 

0 

; 0 
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3.2. 3. 3 Changing  Parameters 


Each  parameter  in  the  display  has  a letter  associated 


with  it.  To  modify  any  of  these  parameters,  type: 

#CH,n  or  #CHANGE,n  where  n a letter  A-H 
The  # specifies  that  it  is  a LIND2  command  and  no  data  is 


sent  to  the  host  until  after  a CB  is  struck.  The  chosen 


parameter  will  be  toggled  to  a new  value.  For  parameters  G 


and  H,  an  additional  parameter  must  be  specified  in  the  CHANGE 


command  following  the  letter  and  a coma.  Some  examples  of 


this  command  are: 


#CH,A 

#CH,G,FILA.DA  1,1:1 


- toggle  the  TTY/TKA  mode 


- change  the  input  file  name 


3.2.3.^  Duplex  Mode 


The  duplex  mode  can  be  toggled  between  full  and  half 


with  a #CH,D  command.  When  in  full  duplex,  each  character 
is  sent  to  the  host  as  it  is  typed  (with  the  exception  of 


LIND2  commands).  To  erase  the  previous  character  sent,  strike 


the  DEL  key.  This  sends  a CNTBL-H  character  to  the  host. 


Either  a CB  or  XMIT  can  be  used  to  specify  a command  termin- 


ator. 


In  half  duplex,  characters  are  sent  only  after  a XMIT 


or  PAGE  XMIT  key  is  struck.  XMIT  transfers  all  characters 


from  the  beginning  of  the  current  line  to  the  cursor  position. 


Thus,  an  entire  line  can  be  typed  and  edited  before  sending, 
or  previous  lines  typed  can  be  resent.  PAGE  XMIT  transfers 


all  characters  from  the  home  position  to  the  cursor  including 


all  embedded  CBs.  If  the  parameter  values  are  being  displayed, 
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the  home  position  is  the  first  line  after  their  display. 

Using  this  capability,  several  lines  can  be  edited  and 

sent  at  one  time.  Care  should  be  taken  when  using  half  > 

I 

duplex  to  ensure  only  the  desired  data  is  transferred. 

Any  extraneous  information  at  the  beginning  of  a line  if 

XMIT  is  used,  or  beginning  of  the  screen  if  PAGE  XMIT  is, 

will  be  sent  to  the  host.  Thus,  if  COMMAND-EDITOR  is  sent 

with  XMIT,  the  entire  line  is  sent  and  will  be  misinterpreted 

by  the  host.  Examples  of  both  modes  are: 

PULL  DUPLEX: 

COMMAND-EDITOR ( CR ) 

CBEO(DEL)ATE 

HALF  DUPLEX: 

COMMAND- (CR) 

EDITOR (XMIT) 

100=linel 
200=line2 

300=1 ine3 ( PAGE  XMIT) 

3.2. 3. 5 Sending  Piles  from  IMLAC  to  Host 

To  8 end  an  existing  IMLAC  file  to  the  host  machine,  the 

following  command  should  be  entered: 

#SEND,dsfn,lfn  - dsfn  is  IMLAC  file  name 

lfn  is  host  file  name 

This  command  effectively  sends  a "COPYSBF, ,lfn"  to  the  host. 

The  file  will  be  displayed  on  the  screen  as  it  is  transferred, 
and  when  it  is  finished,  a £EOF  is  automatically  sent  telling 
the  host  it  is  finished.  The  name  of  the  IMLAC  file  sent  will 
be  displayed  in  the  parameter  information.  The  format  for  the 
IMLAC  file  name  is: 


- types  normal  input 

- deletes  error 


- (CR)  starts  new  line  so 
that  XMIT  only  sends  the 
word  EDITOR 

- sending  several  lines 


0 
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fn.xx  a,b:c;d  - where  fn  = file  name 

xx  *=  two  character  extension 
a,b  * user  area  (such  as  1,1) 
o « disk  (0  or  1) 

d » protection  code 

Only  the  file  name  and  extension  are  required.  The  user  area, 

disk,  and  protection  will  default  to  whatever  the  user  is 

currently  logged  on.  Care  should  be  taken  when  attempting 

to  send  files  from  some  area  other  than  that  currently  logged 

on.  If  the  protection  on  the  file  does  not  allow  the  user  to 

access  it,  the  file  cannot  be  sent.  Some  examples  are: 

#SEND , FILA . DA , LFNl  - sends  FILA.DA  in  current  user 

area  to  host  file  LFNl 

#SEND,FILZ.F4  3,2 :1,LFN  - sends  FILZ.F4  from  area  3,2  on 

Disk-1  to  host  file  LFN 

3. 2. 3. 6 Getting  IMLAC  Files  from  Host 

To  get  a host  file  into  an  IMLAC  file,  the  following 

command  should  be  entered: 

#GET,lfn,dsfn  - where  lfn  = host  file  name 

dsfn  = IMLAC  file  name 

The  format  for  the  IMLAC  file  name  is  the  same  as  specified 
in  the  SEND  section.  This  command  will  issue  a "COFYSBF,lfn, 
OUTPUT"  to  the  host  machine.  The  file  will  be  displayed  as 
it  is  sent.  When  the  transfer  is  complete  (signified  by 
in  editor,  or  "COMMAND"  in  command  mode),  it  is  the  user's 
responsibility  to  strike  LF  which  informs  LIND2  that  the 


transfer  is  complete.  No  keyboard  input  is  recognized  until 
the  LF  is  struck.  If  the  IMLAC  file  being  created  already 
exists  in  the  specified  area,  the  following  question  appears 


) 


If  I is  answered,  the  existing  file  is  deleted  before  the 
transfer  begins.  If  N is  responded,  the  transfer  is  aborted. 
As  in  the  SEND  command,  care  should  be  taken  in  trying  to 
get  an  IMLAC  file  in  a different  user  area.  Examples  of  this 
command  are: 

#GET  LFN1,FILA.F4  - sends  LFNl  to  FILA.F4  in 

current  user  area 

..file. . 

COMMAND- (LF)  - when  file  finished  LF  sent 

#GET  LFN,FIL.DA  3,2:1;400  - sends  LFN  to  FIL.DA  on  3,2 

Disk-1 

♦.file. . 

..(LF)  - when  file  finished  LF  sent 


3.2.3. 7 LIND2  Command  Summary 


Commands : 

#CH,n  - changes  parameter  value 

#SEND,dsfn,lfn  - transfers  IMLAC  to  host  file 

#QET,lfn,dsfn  - transfers  host  to  IMLAC  file 


Special  Key  Characters: 


LF 
. CB 
XMIT 

PAGE  XMIT 

FORM 

TAB 

HOME 

DEL 

FNK  0 

FNK  2 


- terminates  GET 

- terminator  in  full  duplex 

- transmits  line  in  half  duplex 

- transmits  page  in  half  duplex 

- toggles  display 

- erases  screen 
-returns  cursor  to  home 

- deletes  previous  character 

- increases  screen  character  size 

- decreases  screen  character  size 
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3,2.4  STH14 

STB14  simulates  a Tektronix  4014  terminal.  This  permits 
interfacing  to  a host  program  written  to  drive  a 4014  graphics 
screen.  Individual  commands  can  be  found  in  the  *STR14  User's 
Guide ". 

3*2.5  TIS4  and  Others 

TIS4  provides  similar  LINDI  capabilities  for  TTY  commun- 
ication. However,  it  deals  primarily  with  local  and  host 
graphics,  and  will  be  discussed  in  Chapters  6 and  7. 

Other  programs  offer  TTY  communication  as  a means  to 
initiate  host  interaction.  Since  these  programs  do  not  deal 
primarily  with  the  communication  function,  they  will  be  pre- 
sented in  the  chapters  dealing  with  their  respective  function. 
For  strictly  performing  TTY  functions , the  user  should  employ 
LINDI,  LIND2,  or  STB14. 
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CHAPTER  4 
File  Creation/Editing 


4. 1 Function  Overview 

To  fully  utilize  the  local  computing  power  of  the  PDS-4, 
IMLAC  has  provided  several  software  utilities  for  creating, 
editing,  and  compiling  source  programs.  The  primary  storage 
device  for  these  generated  programs  is  the  disk  file.  Source 
files  can  be  created,  loaded  into  memory  and  modified,  compiled 
or  assembled,  and  restored  onto  the  disk. 

File  creation  and  editing  are  treated  as  a single  function 
by  IMLAC.  When  a user  specifies  an  existing  file  to  be  edited, 
the  file  is  loaded  into  memory  and  made  available  for  user 
modification.  When  a non-existing  file  is  requested  for  editing, 
the  system  presents  a blank  file  on  which  the  user  can  create 
the  desired  information.  Information  is  entered  via  the  key- 
board and  interpreted  and  stored  as  ASCII  characters.  If  the 
user  attempts  to  edit  an  existing  file  not  in  ASCII  format, 
the  screen  will  display  unintelligible  symbols  (garbage). 

Once  edited,  the  loaded  file  can  be  rewritten  over  the  original 
file  on  the  disk,  saved  onto  a new  file  which  does  not  destroy 
the  original,  or  discarded  completely.  A means  is  provided 
which  MAY  salvage  files  discarded  in  error. 

Once  the  ASCII  file  is  stored  in  the  desired  format,  it 
is  ready  to  be  accessed  by  the  user.  This  may  include  being 
read  as  a data  file  by  an  executing  program,  compiled  as  For- 
tran into  IMLAC  assembly  code,  or  assembled  into  object  format. 
These  aspects  will  be  discussed  under  the  "Program  Execution" 
function. 


4.2  DFED 

The  Disk  Past  Editor  program  (DEED)  is  the  main  module 
for  creating  and  editing  ASCII  files.  DEED  loads  the  spec- 
ified file  into  memory  and  displays  as  many  lines  as  possible 
on  the  screen.  The  user  can  scroll  the  lines  up  or  down  by 
moving  the  cursor  with  the  keyboard  arrows  to  view  the  entire 
file.  Several  editing  features  are  provided  by  DFED,  and  out- 
lined in  the  "Programmable  Editor  (DEED)"  manual.  Although 
the  key  sequence  for  using  these  features  may  appear  awkward, 
it  is  strongly  recommended  that  they  be  learned  and  utilized, 
for  the  capabilities  offered  provide  a powerful  tool  for 
quickly  generating  and  modifying  files. 


CHAPTER  5 
Program  Execution 

5.1  Funtion  Overview 

IMLAC  provides  a Fortran  compiler,  assembler,  and  binder 
to  produce  executable  object  code.  This  allows  the  user  to 
write  local  Fortran  source  programs  and  execute  them  without 
interfacing  to  the  host  machine. 

Several  limitations  prevent  the  use  of  the  IMLAC  com- 
piler in  the  same  general  sense  as  the  Cyber  Fortran  compiler. 
These  limitations  will  be  mentioned  for  the  awareness  of  the 
new  user. 

One  major  problem  is  the  lack  of  complete  ANSI  standard 
conventions.  This  eliminates  the  ability  to  execute  the  same 
Fortran  program  on  both  the  IMLAC  and  the  host  machines. 
Non-ANSI  standard  differences  are  specified  in  the  "Fortran 
User's  Manual".  Some  examples  are  data  statements,  external 
statements , and  complex  numbers.  These  differences  should  be 
taken  into  consideration  when  creating  a local  Fortran  file. 

Another  limitation  is  the  awkward  subroutine  handling. 
Each  subroutine  must  be  compiled  separately  in  a different 
file,  then  referenced  when  the  program  is  run.  The  problem 
is  heightened  by  the  size  limitation  on  any  single  program 
segment.  If  the  Fortran  compiles  into  assembly  code  longer 
than  4000  (8)  locations,  errors  result  in  the  assembly  phase 
for  the  program.  This  forces  the  programmer  to  break  a large 
Fortran  program  into  separate  subroutines  before  compilation. 

Oraphio  capability  is  another  area  lacking  sophistication. 
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The  local  Fortran  does  support  basic  graphic  functions  as 
described  in  Chapter  14  of  the  "Fortran  User's  Guide",  but 
these  functions  are  limited  and  do  not  take  advantage  of  the 
versatile  graphics  hardware  available. 

Because  of  these  compiler  limitations,  the  user  needs 
to  determine  how  to  best  utilize  the  available  capabilities. 

One  suggestion  is  to  use  the  local  Fortran  as  a post-processor 
of  host  data.  Host  data  can  be  locally  interpreted,  summari- 
zed, and  formatted  for  user  applications.  Another  possible 
Fortran  use  would  be  to  generate  input  data  for  host  programs. 
In  both  examples,  the  Fortran  should  be  developed  specifically 
for  the  IMLAC  system.  The  IMLAC  "Fortran  User's  Guide"  should 
be  closely  referenced  for  specific  capabilities. 

The  compilation  of  a program  generates  an  assembly  lan- 
guage file.  This  file  must  now  be  assembled  to  generate  object 
code.  IMLAC  provides  an  assembler  to  perform  this  function. 

The  assembler  recognizes  IMLAC  mnemonics  and  special  assembler 
macros.  It  translates  the  program  into  machine  code  in  one  of 
two  possible  formats,  object  or  relocatable. 

Object  code  is  completely  self-contained  and  ready  for 
execution.  Relocatable  code  contains  undefined  references 
which  must  be  satisfied  prior  to  execution*  The  process  of 
satisfying  these  references  is  termed  linking  or  binding. 
Binding  is  performed  by  a separate  utility  program  which  in- 
terprets which  files  are  to  be  used  for  satisfying  external 
references,  and  completes  the  object  code* 

The  final  object  code  is  the  version  of  the  program  which 
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is  actually  executed  by  the  IMLAC.  When  the  user  types  in  the 
name  of  a file  (.OB  extension  is  assumed),  IMLAC  searches  the 
disk  for  the  file,  loads  it  into  memory,  and  passes  execution 
to  it. 

The  normal  sequence  of  the  execution  is  file  editing, 
compiling,  assembling,  and  linking.  The  corresponding  program 
formats  are  Fortran  source,  assembly  language,  relocatable, 
and  object. 

5.2  Available  Software 

5.2.1  COKPIL  Subsystem 

When  a user  generates  a Fortran  source  file  (specified 
by  a .F4  extension),  the  compilation  can  be  accomplished  by 
the  one  word  command  COKPIL.  COKPIL  will  perform  the  compila- 
tion and  check  for  any  errors  reported  by  the  Fortran  com- 
piler. If  any  errors  are  detected,  they  will  be  displayed 
for  the  user.  If  no  errors  are  found,  the  subsystem  produces 
an  assembly  language  version  of  the  program  to  be  assembled. 
Befer  to  the  "Fortran-IV  Language  Manual"  for  details  of  this 
subsystem. 

5.2.2  FCOMP 


FCOMP  is  the  name  of  the  Fortran  compiler,  and  is  called 
by  the  COKPIL  subsystem.  The  user  can  execute  FCOMP  directly 
and  perform  his  own  error  checks. 

5.2.3  BUN  Subsystem 

BUN  is  a subsystem  which  uses  the  assembly  language  file 
from  the  compilation,  assembles  it,  binds  it  with  the  Fortran 
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library,  and  executes  the  final  object  code.  This  command 
usually  follows  the  COMPXL  subsystem.  Specifics  on  the  sub- 
system can  be  found  in  Appendix  A of  the  "Fortran- IV  Language 
Manual". 

5.2.4  ASM 

ASM  is  the  IMLAC  assembler.  It  is  called  by  the  BUN 
subsystem,  or  can  be  executed  directly  by  the  user.  Several 
macros  and  options  are  recognized  as  presented  in  the  "Disk 
Assembler  (ASM)  User's  Guide".  If  a program  is  to  be  written 
directly  in  assembly  code,  the  user  should  first  study  the 
"PDS-4  System  Reference  Manual"  to  become  familiar  with  the 
operating  concepts  of  the  system. 

5.2.5  BIND 

BIND  is  the  IMLAC  linker  for  producing  executable  object 
code.  This  utility  is  called  by  the  BUN  subsystem  for  bind- 
ing Fortran  routines  to  an  assembled  program.  Any  user  writ- 
ing assembly  language  code  can  use  BIND  directly  to  reference 
existing  routines  in  the  assembly  program.  Details  of  opera- 
tion can  be  found  in  the  "Linking  Editor  (BIND)  User's  Guide". 

5.2.6  DIDL 

DIDL  is  a debugging  utility  which  allows  a user  to  find 
errors  in  a program  while  executing  it.  DIDL  provides  the 
ability  to  step  through  the  program's  execution,  check  variable 
values,  and  directly  query  memory  locations.  This  is  an  ex- 
tremely useful  tool  for  the  sophisticated  user.  The  "Disk 
Interactive  Symbolic  Debugger  (DIDL)  User's  Guide"  presents 


CHAPTER  6 
Local  Graphics 
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6.1  Function  Overview 

"Local  graphics"  is  a term  used  to  indicate  the  produc- 
tion of  graphic  displays  without  interfacing  to  a host  com- 
puter. Specifically,  a set  of  display  commands  must  be  created 
for  the  display  processor  to  execute.  This  set  of  commands, 
called  the  display  list,  can  be  created  in  several  ways.  The 
most  direct  way  to  create  a display  list  is  to  directly  code 
it  in  assembly  code.  This  method  offers  the  full  range  of 
capability  provided  by  the  display  hardware.  However,  it  is 
impractical  for  all  IHLAC  users  to  learn  the  details  of  the 
assembly  language.  This  method  is  recommended  to  the  exper- 
ienced assembly  programmer  for  its  flexibility  and  efficiency. 

Another  means  for  generating  displays  is  to  execute  a 
Fortran  program  containing  display  commands.  The  display  lists 
developed  by  this  method  are  not  as  efficient  as  if  directly 
coded,  but  require  less  knowledge  on  the  part  of  the  user. 

The  major  drawback  to  this  technique  is  the  inability  to  use 
the  more  sophisticated  hardware  capabilities,  such  as  circle 
generation,  or  the  automatic  reflection  and  rotation.  The 
list  of  available  Fortran  routines  is  located  in  the  "Fortran- 
IV  User's  Manual". 

The  final  means  for  generating  displays  is  IMLAC's  pro- 
vided utility  programs.  These  utilities  are  placed  in  exe- 
cution, and  respond  to  user  commands  to  draw  lines,  circles, 
and  alphamunerics.  In  addition,  subpictures  can  be  defined 


for  rotation,  scaling,  and  translation.  The  final  display 
Image  can  be  saved  to  a disk  file  for  future  reference. 
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6.2  Available  Software 
6.2.1  TIS4 


TIS4  is  the  most  versatile  program  available  for  cre- 
ating complex  displays.  It  can  be  used  both  interactively 
with  a host,  or  in  a local  mode.  The  host  mode  is  discussed 
in  the  host  graphics  section.  When  using  it  locally,  TIS4 
accepts  commands  from  the  keyboard  to  create  figures,  edit 
subpictures,  and  load  or  store  displays.  The  light  pen  capa- 
bility is  used  to  select  subpictures  for  editing.  The  complete 
command  set  is  found  in  the  "Terminal  Interface  System  (TIS) 
User's  Guide". 

0 

6.2.2  SYHBL4 

SYMBL4  is  used  to  define  and  store  entire  sets  of  sym- 
bols. A grid  is  produced  on  the  screen  to  allow  the  user  to 
generate  symbols  16  times  their  normal  size.  These  symbols 
can  be  saved  in  a local  inventory  or  saved  on  a disk  file. 

The  format  for  saving  the  information  to  disk  is  specified  by 
the  user  as  either  source  or  object.  The  source  code  is  in 
display  assembly  language,  and  can  be  directly  inserted  into 
an  assembly  program  or  Fortran  program  using  the  embedded 
assembly  code  feature.  Instructions  for  SXHBL4  usage  can  be 
found  in  the  "SYMBOLFOHM  Character  Generating  Program  User's 
Guide". 
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CHAPTER  7 
Host  Graphics 

7.1  Function  Overview 

A major  advantage  of  computer  graphics  is  the  ability  to 
interact  with  an  executing  program  through  the  display.  "Host 
graphics"  refers  to  this  interaction  between  the  IMLAC  display 
screen  and  an  executing  program  on  a host  computer.  The  gra- 
phics system  on  the  IMLAC  must  be  able  to  accept  and  interpret 
oommands  from  the  host,  perform  the  display  functions,  and 
transmit  information  from  the  user  back  to  the  host. 

IMLAC  provides  this  capability  in  a fashion  similar  to 
its  TTY  programs.  A utility  program  is  executed  which  can 
receive  and  transmit  data  to  a host  through  the  modem.  The 
user  must  log  into  the  host  system,  and  place  a host  program 
into  execution.  This  program  generates  and  sends  graphic 
commands  to  the  IMLAC.  The  local  utility  interprets  the 
commands,  and  performs  the  desired  functions.  If  the  command 
requests  user  interaction,  the  local  utility  will  accept  the 
user  response  and  transmit  it  back  to  the  host. 

7*2  Available  Software 

7.2.1  TIS4/GCS 

TIS4  was  briefly  described  in  the  local  graphic  section. 
It  has  an  interactive  capability  which  was  specifically  de- 
signed to  interpret  commands  from  the  Graphics  Compatability 
System  (GGS)  library.  To  use  TIS4,  the  user  creates  a Fortran 
program  on  the  host  machine  which  contains  calls  to  the  GCS 
library  routines.  The  user  then  executes  the  TIS4  utility 


which  has  a TTY  function,  and  logs  into  the  host.  Before 
executing  the  host  program,  the  user  must  attach  the  appro- 
priate library  which  contains  the  GCS  driver  for  the  IKLAC. 
When  the  host  program  is  executed,  this  driver  will  transmit 
the  graphic  commands  to  TIS4  to  perform.  Specific  details 
for  this  function  are  available  in  the  "Graphics  Compatability 
System  (GCS)  Programmer's  Manual"  and  the*TIS  User's  Guide". 

7.2.2  GTS/GBAPHELP 

GTS  operates  similarly  to  TIS4.  GTS  is  executed  on 
the  IMLAC,  and  it  allows  TTY  communication  for  logging  onto 
the  host.  The  graphic  commands  from  the  host  are  generated 
using  the  GBAPHELP  library.  These  calls  are  different  from 
those  available  in  GCS;  three  dimensional  commands  are  not 
available,  and  different  formats  exist.  These  library  rou- 
tines were  written  for  a 16-bit  minicomputer,  and  are  not 
available  for  CDC  host  computer  operation. 


CHAPTER  8 
File  Maintenance 


8.1  Function  Overview 

IMLAC  provides  several  utilities  to  help  the  user  manage 
the  disk  file  system  described  in  Chapter  2.  These  utilities 
perform  such  tasks  as  file  modification,  directory  querying, 
and  file  dumping.  All  utilities  listed  are  presented  in  detail 
in  the  "Disk  Operating  System  User's  Manual". 

8.2  Available  Software 

DELETE  - removes  a file  from  the  disk. 

GET  - retrieves  a file  to  the  current  user  area  from  another 
area  or  disk.  This  utility  is  used  to  save  files  to 
a removable  disk. 

MN/NM  - translates  files  from  ASCII  to  binary  or  vice-versa. 

PK/KP  - pack  and  unpack  information  on  files. 

DIBEKT  - displays  files  contained  in  a specific  user  area. 

DPBINT  - prints  the  directory  to  a printer. 

PBINT  - prints  an  ASCII  file  to  the  printer. 

RENAME  - changes  the  name  of  an  existing  file. 

FLUSH  - deletes  all  files  not  belonging  to  user  area  1,1. 

This  utility  should  be  USED  WITH  CABE. 

Several  other  programs  are  available  for  copying  entire 
disks,  error  checking,  and  specifying  system  parameters. 

These  functions  should  be  used  with  care  because  of  their 
ability  to  "clobber"  file  information.  Reference  the  oper- 
ating manual  for  specific  instructions. 
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CHAPTER  9 
Miscellaneous  Functions 


The  following  programs  are  not  Involved  directly  with 
any  of  the  described  functions,  and  are  mentioned  here  for 
user  reference. 


9.1  JOD 

JOD  is  the  IHLAC  text  editor  program.  It  relies  mainly 
on  the  DFED  commands  for  entering  and  editing  text.  Once 
entered,  the  information  can  be  automatically  justified, 
paged,  and  contented.  The  "JOD  Text  Editing  System  User's 
Guide"  contains  specific  details  for  using  the  system. 

9.2  SIZE 

SIZE  is  a locally  created  utility  to  allow  the  user  to 
select  the  screen  print  size  for  the  MONITOR.  The  format  for 
executing  this  utility  is: 

SIZE/n  - where  n is  a scale  from  1-7 
This  parameter  will  only  affect  the  screen  size  when  the 
MONITOR  is  in  execution. 

9.3  MSG 

MSG  was  locally  developed  to  permit  a one  line  message 
to  be  displayed  with  the  system  parameters  of  the  MONITOR. 

The  format  for  this  function  is: 

KSG/message  to  be  displayed...' 

The  MONITOR  will  display  the  same  message  until  changed  with 
another  MSG  command. 


149 


2ita 


Dennis  L.  Schweitzer  was  born  on  11  September  1952  in 
Canton,  Ohio.  After  graduating  from  Lehman  High  School  in 
1970,  he  continued  his  education  at  the  United  States  Air 
Poroe  Academy,  Colorado  Springs,  Colorado.  On  5 June  1974-, 
he  was  graduated  with  the  degree  of  Bachelor  of  Science  and 
was  commissioned  a Lieutenant  in  the  United  States  Air  Force. 
Following  graduation,  he  spent  three  years  as  a computer 
systems  analyst  at  Headquarters , Strategic  Air  Command,  Offutt 
AFB,  Omaha,  Nebraska.  He  was  assigned  to  the  Air  Force  In- 
stitute of  Technology  in  August,  1977. 

Permanent  address:  5612  Brentwood  Ave. 

North  Canton,  Ohio  44720 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (Whan  PmfaHwO, 

I REPORT  DOCUMENTATION  PAGE 


1.  REPORT  NUMBER  2.  OOVT  ACCESSION  NO. 

AFIT/GCS/EE/79-3 

«.  TITLE  (and  Submit) 

EVALUATION  OP  AN  EXISTING  COMPUTES 

SYSTEM  USING  STRUCTURED  ANALYSIS  

TECHNIQUES  . 

________ 

Dennis  L.  Schweitzer 

Captain  USAP  ' 

•.  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 
1.  RECIPIENT'S  CATALOG  NUMBER 


S.  TYPE  OF  REPORT  * PERIOO  COVERED 


MS  THESIS 


^PERFORMING  OTG.  REPORT  NUMBER 


t.  CONTRACT  OR  GRANT  NUMBERfl.) 


10.  PROGRAM  ELEMENT,  PROJECT.  TASK 
AREA  & WORK  UNIT  NUMBERS 


Air  Force  Institute  of  Technology  (AFIT/E 
Wright-Patterson  AFB,  Ohio  45433 


II.  CONTROLLING  OFFICE  NAME  AND  AOORESS 

Air  Force  Flight  Dynamics  Laboratory 
( FBR ) 

Wright-Patterson  AFBr  Ohio  454^3 

U.  MONITORING  AGENCY  name  a ADDRESS^*/  ditlmront  from  Controlling  Oflieo) 


12*  report  DATE 

Mar  1979  r" 

IS.  NUMBER  OF  PAGES  — — — 

158 

15.  SECURITY  CLASS,  (ol  (Ala  report) 

Unclas 

IS*.  OECLASSI  FI  CATION/ DOWNGRADING 
SCHEOULE 


I IS.  DISTRIBUTION  STATEMENT  (ol  Ihla  Report) 


Approved  for  public  release;  distribution  unlimited. 


1 17.  DISTRIBUTION  STATEMENT  (Oi  thm  obmtrmct  onfrod  in  Block  20,  II  dllloront  from  Repo H) 


APPROVED  FOR  PUBLIC  RELEASE  AFR  19017. 


IB.  supplementary  notes 


P.  lUPPS^HaJor,  054*1  ^ ® ^AY  ^79 

Pi r LCtor  n p r r,  r>n  

IB.  KEY  WORDS  (Continue  on  rarer  aa  alda  It  nacoaaaty  and  Identity  by  block  nimbar} 

Computer  Software 
Structured  Analysis 
Software  Requirements 
— ^Requirements  Analysis 

20.  ABSTRACTYConHiMM  on  rarer  aa  alda  It  ntcaaaary  and  Identity  by  block  number) 

This  thesis  is  an  evaluation  of  an  existing  computer 
graphics  system  using  structured  analysis  techniques.  The 
systera  evaluated  is  the  IMLAC  PDS-4  minicomputer.^  the  Air 
Porca-i»l±glit  Dvwiuilcq  T.ahfinafnry,  UrM  AFB. 

fWhe  technique  used  in  the  evaluation  is  Derformed  in 
three  steps.  First,  the  existing  system  is  modeled  into  its 


00  i jan*7i  1473  EOtTtON  OF  I NOV  ••  IS  OBSOLETE 


JLt 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  fWh*»  Dale  Entered) 


tCUWITV  CLASSIFICATION  OF  THIS  PACCr*ft«i  Data  Kmtwf*) 


iBlock  20. 


logical  equivalent  using  bubble  charts.  This  model  shows 
the  flow  of  data  through  the  system,  and  the  activities 
performed  on  that  data.  Second,  a similar  model  is  produced 
describing  the  required  system  as  defined  by  the  users. 

This  model  is  a representation  of  the  users*  desires  and 
requirements,  and  is  similar  to  a model  which  might  be 
produced  during  the  requirements  definition  Dhase  of  a 
computer's  life  cycle.  The  third  step  is  to  compare  the 
two  models  to  evaluate  the  existing  system's  effectiveness, 
and  reveal  areas  requiring  modification  for  full  utilization 
of  the  system. 

Following  the  evaluation,  several  recommendations  and 
changes  are  proposed  to  increase  the  system's  capability  to 
meet  the  user  requirements. 


UNCLASSIFIED 


